Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Houman <houmie@gmail.com>
To: Roman Mamedov <rm@romanrm.net>
Cc: 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 12:40:46 +0100	[thread overview]
Message-ID: <CABBZOsmMSnspA6iTCvv0QZLL9KVtGSvt+KPAMqWecOmKubou4Q@mail.gmail.com> (raw)
In-Reply-To: <20220601145143.75234bd8@nvm>

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 11: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 [this message]
2022-06-01 12:41         ` Frank Carmickle

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=CABBZOsmMSnspA6iTCvv0QZLL9KVtGSvt+KPAMqWecOmKubou4Q@mail.gmail.com \
    --to=houmie@gmail.com \
    --cc=icepic.dz@gmail.com \
    --cc=rm@romanrm.net \
    --cc=wireguard@lists.zx2c4.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).