wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Christopher Bachner <hello@chrisbox.org>
To: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: performance query
Date: Fri, 8 Mar 2019 17:45:31 +0100	[thread overview]
Message-ID: <CAKJniYTMuV5TG_iWMQXXhGsdwQGX-f=QnMboqgUqXM-7CJcMQQ@mail.gmail.com> (raw)
In-Reply-To: <CAJwvAotKEmjTOd0U9vMX0taZYTc4YKygnKX5sw79ySgdXc0ebg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3669 bytes --]

Hi Scott,

From experience, I can tell you I was able to get my Gbit saturated over
Wireguard to a server in a datacenter.

You need to have good routing, obviously.

Greetings,

Christopher Bachner

On Fri, Mar 8, 2019 at 4:41 PM Scott Lipcon <slipcon@gmail.com> wrote:

> Thanks for the suggestions - I'll need to do some more experimentation
> when I get back in the office, but I think you're on to something, perhaps
> with the router at Location B in my examples.    I did a straight UDP speed
> test with iperf3, and that worked fine - over 500Mbit/sec - there shouldn't
> be anything funny with MTU going on, nor any IPv6... however I did two
> additional tests:
>
> At my main location, I've got another "low end" box on the same local
> network as the "server" - this one is an intel Atom CPU - with that I was
> able to get about 585Mbit/sec (compared to the 930-940 without wireguard).
>
>
> I've got a 3rd location available - actually a low end VM on AWS - this
> one gets around 300Mbit unencrypted, and actually tested above that via
> wireguard - I assume thats just normal fluctuation, but seems to point the
> finger to something specific at location B, my office.    I'll continue to
> investigate and update if I figure anything out... it'll probably be at
> least a week before I get anywhere though, due to work travel.
>
> Thanks again,
> Scott
>
>
> On Fri, Mar 1, 2019 at 5:18 AM Kalin KOZHUHAROV <me.kalin@gmail.com>
> wrote:
>
>> On Fri, Mar 1, 2019 at 11:11 AM Scott Lipcon <slipcon@gmail.com> wrote:
>> >
>> > I've been experimenting a bit with Wireguard on several ubuntu systems,
>> and am not seeing the performance I'd expect based on the numbers at
>> https://www.wireguard.com/performance/
>> >
>> > I'm wondering if there is a configuration setting i'm missing or any
>> better way to debug this.
>> >
>> > Testing between two locations - both have nominally 1Gbit internet
>> connections from the same provider.
>> >
>> > At location A:
>> > 1) Ubuntu 18.04 "server" - i7-4790K CPU @ 4.00GHz
>> > 2) Ubuntu 16.04 client - i5-3470 CPU @ 3.20GHz
>> >
>> > At location B:
>> > 3) Ubuntu 18.04 client - Celeron N2808  @ 1.58GHz
>> > 4) Ubuntu 18.04 client - Virtual Machine - Xeon(R) Gold 6126 CPU @
>> 2.60GHz
>> >
>> >
>> > Using iperf3 for all tests, with 8 threads, but that doesn't seem to
>> matter significantly.
>> >
>> > Between 1 & 2, via gigabit LAN - 940 Mbit/sec.
>> > Between 1 & 2, via WireGuard - 585 Mbit/sec
>> > - I might have expected a bit higher, but this is certainly acceptable.
>> >
>> > Between 3 and 1, direct iperf3 - 580 Mbit/sec
>> > Between 3 and 1, WireGuard - 73 Mbit/sec
>> >
>> > At this point I was guessing WireGuard was CPU limited on this little
>> Celeron, so I set up the Xeon VM (#4):
>> >
>> > Between 4 and 1, direct iperf3 - ~600 Mbit/sec
>> > Between 4 and 1, WireGuard - 80 Mbit/sec
>> >
>> > In other words, the much faster VM is only a tiny bit faster that the
>> celeron.
>> >
>> > Any suggestions?
>>
>> A lot can go wrong speed-wise "on the Internet"...
>>
>> What sits in between those hosts that you have control of (routers,
>> switches, firewalls...)?
>> IPv6 involved at all?
>> ISP having throttling policy for "UDP we don't understand"?
>> Play with the MTU, you might be hitting some fragmentation issues that
>> a weak router is not handling fast enough.
>> Play with Wireshark (new 3.0 even has support for wireguard
>> protocol!), capture some traffic, look for any transmission errors.
>>
>> Cheers,
>> Kalin.
>>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 5629 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

  reply	other threads:[~2019-03-20 22:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26 20:53 performance query Scott Lipcon
2019-03-01 10:18 ` Kalin KOZHUHAROV
2019-03-02  4:08   ` Scott Lipcon
2019-03-08 16:45     ` Christopher Bachner [this message]
2019-03-11 16:23     ` Scott Lipcon

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='CAKJniYTMuV5TG_iWMQXXhGsdwQGX-f=QnMboqgUqXM-7CJcMQQ@mail.gmail.com' \
    --to=hello@chrisbox.org \
    --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).