[dspillett]

> you will bottleneck at ~300Mbit\s.

Any idea where the bottleneck was there? CPU use? Protocol latency? I'd be interested to see some test results around that if you know of any that have been published.

A little anecdotal information: some years ago I did a CPU-load test with OpenVPN on a diminutive Atom-based netbook as the client, and it maxed out at around 95mbit/s on a 100mbit/s network (actually a gbit network, but the netbook only had a 100mbit NIC itself) while just doing simple bulk transfers.

[chrisper]

You could start here:

https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_...

>It is easily possible to saturate a 100 Mbps network using an OpenVPN tunnel. The throughput of the tunnel will be very close to the throughput of regular network interface. On gigabit networks and faster this is not so easy to achieve. This page explains how to increase the throughput of a VPN tunnel to near-linespeed for a 1 Gbps network.

I think the protocol just wasn't designed for such high speeds.

[eptcyka]

Have you read the code? It's woefully unparallelisable and is written to support more platforms rather than work better on any single one of them.

[dspillett]

> woefully unparallelisable

It certainly doesn't use multiple cores for a single connection, though I've never tested (or reviewed the code) to see if it does manage to spread the computational load of multiple connections over more CPU resource.

I've not read the above linked article in detail (no time ATM) but there seems to be mention of offloading AES calculations to compatible hardware, so the bottleneck would appear to be CPU use.

[cbhl]

Does using multiple cores on a single NIC actually speed up a network connection? If you're doing gigabit with 1500 byte packets, you get 12 ms to encrypt and process each packet -- I'd expect any cross-CPU synchronization to easily blow through that.

[05]

If the bottleneck is encryption speed, then you can definitely improve perf by spreading packets across the cores. Inter-core synch isn’t that expensive, and 12us is 24000 cycles on a 2GHz CPU. cmpxchg costs ~20 cycles (https://stackoverflow.com/questions/4187914/average-latency-...).

PS. And you don’t need to submit/receive packets to NIC one by one, either; those things support DMA scatter/gather.

[cbhl]

That's a really helpful response; thanks!

[vel0city]

Earlier you claim you will only ever hit ~300Mbit, but then you link to an article where the author hit 885Mbit throughput after tweaking a few settings and ensuring OpenSSL was using AES-NI.

[chrisper]

Yes. But that article never worked for me.