tinc 1.1pre10 slower than tinc 1.0, experimentalProtocol even more

[Henning Verbeek]

On Wed, Apr 16, 2014 at 11:37 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> On Wed, Apr 16, 2014 at 10:23:23PM +0200, Henning Verbeek wrote:
>> Everything here as it should be?
>
> Yes. However, I already found a bug; even though the PMTU discovery worked
> correctly, tinc 1.1 still allows slightly larger packets, which will then be
> sent via TCP instead of UDP. This causes the bad performance you see. I will
> fix that this weekend, I hope.

Great, happy to test it (although not before mid next week).

> However, I added an option in sptps_test to use a tun device instead of
> standard input/output, and if I then use that to configure a simple
> point-to-point VPN, then the throughput drops to 500 Mbit/s, with 100% CPU
> utilization on the slowest node (an i3-3220T at 2.8 GHz). This would then
> suggest that tun/tap handling is a bottleneck. I'm not surprised by that, it
> does involve a lot of context switches between tinc, the kernel and the program
> generating the actual network load (like iperf).

Thanks, that explains a lot and makes sense. In fact, it has driven me
to test a kernel-based implementation (IPsec in transport mode), with
quite good results. Obviously it's not comparable to tinc (especially
with regards to routing and finding paths through the mesh), but it
might fit my requirement (near-Gbit-throughput with low CPU footprint,
peer-to-peer, small number of nodes).