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
prev parent 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).