Re: [Make-wifi-fast] Estimating WiFi congestion using different-prio pings

[Pete Heist <peteheist@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]


> On Jan 13, 2018, at 12:49 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Any prioritisation of ICMP may just be because ICMP replies are
> generated by the kernel, whereas other traffic goes all the way to the
> userspace application generating it. However, it is certainly possible
> that ICMP is being prioritised - some people do that in an effort to
> game benchmarks...

I somehow missed this comment from before. Here’s what makes me think this is more than just kernel vs userspace, and something Ubiquiti may be doing, at least in their M series firmware:

- To measure overhead, between a RasPI (client) and an EdgeRouter-X (server), I see only a 354µs difference between ping’s mean RTT and irtt's mean RTT when tested with 100 packets over direct cabled Ethernet (865µs - 511µs). I assume that this overhead will remain about the same for the same client and server devices, regardless of what else lies between them.

- Next, ping vs irtt (mean rtt of 100 packets) to the same EdgeRouter-X over an unloaded Internet connection where the CPE is a Ubiquiti PowerBeam M5-400:
	- ping: 17.03ms
	- irtt: 20.7ms

- Next, ping vs irtt (mean rtt of 100 packets) to the same EdgeRouter-X, same Internet connection, but with a saturated upload and no AQM:
	- ping: 22.9ms
	- irtt: 90.23ms

Saturation seems to have a much larger impact on UDP than ICMP.

This is only a rough test and I’ll need to reproduce this in my lab setup when it’s up again. That will remove all devices along the route as possible sources of this behavior. But since I know FreeNet isn’t doing this in their backhaul I’m fairly certain that’s what’s going on.

I’ll update with some results later when repro’d in the lab with NSM5s…


[-- Attachment #2: Type: text/html, Size: 6484 bytes --]