> -SNIP-
> I haven't taken the time to fully understand the tests you've done etc.
> [And it does seem you are not some neophyte blindly hacking your way
> through this...]
>
> However, I will tell you that it's *very* common for people to do things
> that appear very similarly as you describe, and find the IPSec throughput
> is vastly better then OpenVPN. [That's always been my experience in any
> benchmarking I've done - and I've done some.] Each time I've seen it
> discussed - I've seen repeated threads all pointing to the kernel vs user
> space arguments.
>
> And all my own testing also shows that to be the case.
>
> IIRC, in the platforms I've tested, OVPN isn't CPU constrained - the
> connection will max out throughput far earlier than CPU exhaustion. IPSec
> will scale more or less directly with CPU performance - and at max
> throughput the CPU handling encryption will max out. (I suppose this might
> not be true in a system with in-hardware AES or other encryption
> off-loading - and the ethernet interface will become the bottleneck, not
> the CPU - but where I've run tests, that was never the case. It's,
> admittedly, been a while since I've done any real throughput tests on a
> test-bed setup.)
>
> TK> Again, keep in mind that full wire speed is realized with no vpn, and
> TK> with IPSec.
> TK> So, to reason this through a little:
>
> 1) TK> - No vpn = fast.
> 2) TK> - IPSec = fast.
> 3) - OVPN->>OVPN = even faster
> 4) - OVPN->>OVPN->routing/hardware = slow, down to about 200Mbps from
> 1+Gbps.
>
>
> I may certainly be wrong, but I'd be *really* skeptical about #3. I've
I may be wrong but I think it's simply the effect of LZO compression and
the nature of transferred data. Without LZO (or any other compression like
LZ4) I'm quite sure the speed is almost identical to #2 with IPSec.
> *never* seen a case where the performance of OpenVPN is better than IPSec
> on the same platform.
>
> And if #3 is wrong, your "tinkering" with #4 will never yield something
> useful.
> Obviously, I'd want to be pretty sure the straight OVPN <-> OVPN tests are
> accurate before trying to solve #4.
Still, I believe a dump on host B should reveal where the bottleneck is.
I'm also not sure the simple 'ethtool -K {dev} rx off tx off' is enough
here. Did you also look at ethernet features
- scatter-gather
- TCP segmentation offload
- UDP fragmentation offload
- generic segmentation offload
- generic receive offload
I know that the default settings can slow down data transfers horribly
with some traffic shaping configurations. I expect they can also have an
effect here.
Regards,
Simon
- large receive offload
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
