On 22/08/15 21:57, Gert Doering wrote: >> > I've read about IPSEC being 'faster' than OpenVpn but then there's a lot >> > of disagreement on that too. Plus the fact that I have even LESS of a >> > clue about IPSEC :-/ > IPSEC can go to higher speeds if done right because it's done in the kernel, > so no "copy packet to userland process, encapsulate, copy it back to kernel > space, send out" - but that's again talking about gbit ranges, not about > ~20 Mbit/s
Actually, IPSEC can do better because it doesn't necessarily have a TUN/TAP adapter. JJKs performance analysis on gigabit speeds seems to hit a nerve with either encryption or the tun driver. However, if the IPSEC client uses a UDP connection and a local TUN/TAP device the performance drops more easily. I believe the reason is because a software driver for a virtual nic lacks hardware offload support. In addition hardware NICs have fairly efficient multi-queue support too. Recently the tun driver have gotten multi-queue support which can help some of the performance difference, but to truly benefit from that in VPN context, OpenVPN needs to push data in parallel to multiple queues - which can be quite tricky to benefit from in a single threaded application. It also depends where the true bottle neck lays; does OpenVPN starve the TUN/TAP device or is it the TUN/TAP device not processing packets fast enough? I'm leaning towards the latter, as turning off hardware offloading support can degrade the performance of hardware NICs somewhat closer to the TUN/TAP driver. Just my unfiltered 2 cents before calling it a day for today. -- kind regards, David Sommerseth ------------------------------------------------------------------------------ _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
