[Babel-users] latency in WLAN-SI

[Mitar]

Hi!

On Tue, Dec 15, 2015 at 2:16 AM, Dave Taht <dave.taht at gmail.com> wrote:
>> Or we have a very short buffer. ;-)
>
> You certainly know how to tweak me!

In fact, we do not yet have anything like that configured, I was just
teasing. ;-)

But maybe upstream ISPs have.

> Do you have something like smokeping configured? I would love to see
> data on not just the vpn issues but on the latencies across the mesh.

Valent is running Smokeping from Croatia towards our server just for
this reason (after we discovered the issues). He might be able to give
you access to the VPS he runs there if you want to do more active
testing.

http://95.85.26.162:81/smokeping/smokeping.cgi?target=Wlan-si.node2

We do measure latencies from the central server (which is running
nodewatcher monitoring system) to all nodes for different packet sizes
every 5 minutes.

> In lui of deploying smokeping everywhere I've been thinking of adding
> a lightweight latency test to flent, where we just test lightweight
> udp and icmp continuously with, say, a 1sec or even 60 sec period, to
> dozens or hundreds of hosts, for hours at a time, all the time....
> Smokeping's basic plot is good, but flent can do a better job of
> aggregating data across more variables. Another approach would be
> embed timestamps in the needed overhead traffic (be that babel or
> other) and get everything synced up via ntp.......

Currently we use fping. Feel free to propose other stuff we should be measuring.

> As best as I recall your vpn was pure udp, no crypto, no retries.... I
> see in your (nice!) web interface that you track if a node is
> reachable, but not an observed rtt.

We also measure RTT.

> Could you clarify the behavior of your vpn? vpn's over tcp will never
> lose packets. vpns that do crypto tend to bottleneck on the crypto
> step and drop packets in the read side of the socket. nearly anything
> using the tun/tap interfaces tends to be slow, the recent Foo over UDP
> stuff corrects some of that:
> https://www.netdev01.org/docs/herbert-UDP-Encapsulation-Linux.pdf

We use L2TPv3 UDP pseudowire Linux kernel tunnels (so Ethernet/L2 over
UDP). Our VPN is just a broker for those. So no crypto, UDP, and
in-kernel tunneling for no context switches. The latter was require to
get anything more than 5 Mbit/s of VPN throughput on Foneras. When you
have a lot of fiber you tend to like using it all, if you can. :-)


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m