wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Scott Lipcon <slipcon@gmail.com>
To: Kalin KOZHUHAROV <me.kalin@gmail.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: performance query
Date: Mon, 11 Mar 2019 12:23:52 -0400	[thread overview]
Message-ID: <CAJwvAov9roSCgWf-op-dY+N7cwoeTvUx--NHDbz7dx=3goaZ9A@mail.gmail.com> (raw)
In-Reply-To: <CAJwvAotKEmjTOd0U9vMX0taZYTc4YKygnKX5sw79ySgdXc0ebg@mail.gmail.com>


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

Just to provide a followup, in case anyone is interested - The office
router is a Sonicwall TZ 500.   Disabling DPI on the zone in question
caused the performance to dramatically increase.... 655Mbit for no VPN, and
about 600 via Wireguard.... thanks for the tip to look at the firewall.

Scott


On Fri, Mar 1, 2019 at 11:08 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.
>>
>

[-- 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

      parent reply	other threads:[~2019-03-20 22:24 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
2019-03-11 16:23     ` Scott Lipcon [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='CAJwvAov9roSCgWf-op-dY+N7cwoeTvUx--NHDbz7dx=3goaZ9A@mail.gmail.com' \
    --to=slipcon@gmail.com \
    --cc=me.kalin@gmail.com \
    --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).