From: Frank Carmickle <firstname.lastname@example.org> To: Houman <email@example.com> Cc: Roman Mamedov <firstname.lastname@example.org>, Janne Johansson <email@example.com>, WireGuard mailing list <firstname.lastname@example.org> 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 <email@example.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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).