Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Frank Carmickle <frank@carmickle.com>
To: Houman <houmie@gmail.com>
Cc: Roman Mamedov <rm@romanrm.net>,
	Janne Johansson <icepic.dz@gmail.com>,
	WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: How to improve Wireguard speed?
Date: Wed, 1 Jun 2022 08:41:05 -0400	[thread overview]
Message-ID: <E410057D-B5FE-466B-9B0D-E9ADA7B48298@carmickle.com> (raw)
In-Reply-To: <CABBZOsmMSnspA6iTCvv0QZLL9KVtGSvt+KPAMqWecOmKubou4Q@mail.gmail.com>

It's almost certainly the iPhone that's the slow part. The wireguard implementation on iOS is running in userspace.

--FC

> On Jun 1, 2022, at 7:40 AM, Houman <houmie@gmail.com> wrote:
> 
> Thanks Roman.
> 
>> So did you apply both of that, and what was the effect?
> 
> I will create a new environment this afternoon and test the MTU
> changes mentioned earlier and investigate the outcome.
> 
>> What are the other point that you test against, is it another VPS (better if
>> you could try with that), or your home connection?
> 
> The iPhone is connected via Wifi to the home network, which is 500 Mbps / fibre.
> I have a code snippet on the iPhone that downloads a 1 GB test file
> from my AWS bucket (London) for 10 seconds. Then measures
> totalBytesWritten / time elapsed / (1024.0 * 1024.0) * 8.0.
> Which is the formula for Mbps as far as I am aware.
> 
> Client (iPhone) --> server (VPS) --> S3 (AWS) = 117 Mbps
> Client (iPhone) --> S3 (AWS) = 506 Mbps
> 
> I run this once the Wireguard connection is established and I get 117
> Mbps. Then I disconnect the VPN and run the same code again to fetch
> the test file without VPN that comes down to 506 Mbps. Client
> (iPhone), server (VPS) and S3 (AWS) are all in located London, UK.
> 
> I have run your iperf test.  On the VPS the Lost/Total Datagrams is
> 0%. On the client (Mac) the Lost/Total Datagrams is 0.13%.  This test
> proves that the ISP isn't messing around with UDP.
> 
> [  5] local 192.168.1.101 port 62103 connected to xxxxx port 5201
> [ ID] Interval           Transfer     Bitrate         Jitter
> Lost/Total Datagrams
> [  5]   0.00-1.00   sec  59.5 MBytes   499 Mbits/sec  0.034 ms  0/44538 (0%)
> [  5]   1.00-2.00   sec  59.7 MBytes   500 Mbits/sec  0.012 ms  0/44677 (0%)
> [  5]   2.00-3.00   sec  59.3 MBytes   497 Mbits/sec  0.021 ms
> 15/44400 (0.034%)
> [  5]   3.00-4.00   sec  60.0 MBytes   503 Mbits/sec  0.015 ms  0/44913 (0%)
> [  5]   4.00-5.00   sec  59.5 MBytes   499 Mbits/sec  0.020 ms  0/44588 (0%)
> [  5]   5.00-6.00   sec  59.3 MBytes   498 Mbits/sec  0.018 ms
> 219/44662 (0.49%)
> [  5]   6.00-7.00   sec  59.6 MBytes   500 Mbits/sec  0.065 ms  0/44633 (0%)
> [  5]   7.00-8.00   sec  59.6 MBytes   500 Mbits/sec  0.037 ms  0/44614 (0%)
> [  5]   8.00-9.00   sec  59.6 MBytes   500 Mbits/sec  0.024 ms  0/44633 (0%)
> [  5]   9.00-10.00  sec  59.2 MBytes   497 Mbits/sec  0.024 ms
> 339/44686 (0.76%)
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Jitter
> Lost/Total Datagrams
> [  5]   0.00-10.01  sec   596 MBytes   500 Mbits/sec  0.000 ms
> 0/446756 (0%)  sender
> [SUM]  0.0-10.0 sec  657 datagrams received out-of-order
> [  5]   0.00-10.00  sec   595 MBytes   499 Mbits/sec  0.024 ms
> 573/446344 (0.13%)  receiver
> 
> 
> For now I'm out of ideas. I will try to play around with MTUs this
> afternoon and see what happens.
> Thanks,
> 
> 
> 
> 
> 
>> It could be your home provider has different speed limits (shaping) in place
>> for UDP. Should be possible to test this with:
>> 
>>  iperf3 -s                        # on VPS
>> 
>>  iperf3 -u -b 500M -c <VPS IP> -R # on the other side
>> 
>> And then see how many "Lost/Total Datagrams" (xx %) you get. A high percentage
>> would indicate that the actual top speed for UDP is less than 500Mbit by this
>> value.
>> 
>> --
>> With respect,
>> Roman


      reply	other threads:[~2022-06-01 12:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-01  7:42 Houman
2022-06-01  8:50 ` Janne Johansson
2022-06-01  9:07   ` Houman
2022-06-01  9:51     ` Roman Mamedov
2022-06-01 11:40       ` Houman
2022-06-01 12:41         ` Frank Carmickle [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E410057D-B5FE-466B-9B0D-E9ADA7B48298@carmickle.com \
    --to=frank@carmickle.com \
    --cc=houmie@gmail.com \
    --cc=icepic.dz@gmail.com \
    --cc=rm@romanrm.net \
    --cc=wireguard@lists.zx2c4.com \
    --subject='Re: How to improve Wireguard speed?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).