From Dave Taht's presentation at Linux Plumbers Conference 2016, the results of some of our work on wifi queue control and airtime fairness. Note that the "good" one is actually the one that looks like an insane paint splatter, but watch out: the y axes are very different between the two. The insane paint splatter is actually a much better contained range.
 Well, GFiber paid for some big parts of of it and I provided, uh, psychotherapy.
So I mostly don't have much trouble with impostor syndrome at work. But I do when I test the wifi in my room at a random hotel in Seoul.
I'm pretty sure we're in the middle of the "Japanese car manufacturers in the 1990s" moment, for network connectivity this time.
An encyclopedia of failure, volume 1 of n. The blue lines are tcp_transonic (my lobotomized congestion control). Each line is a test run, and each box is a particular test device. The ideal answer is y=0 for all x (where x is time, and y is how far behind realtime you've fallen). I've filtered down to only the boxes that have run both with and without tcp_transonic, and have failed at least once (ie. y < -2 for some x).
Or maybe, a bit more simply, the line slants down toward the right when the wifi is too slow, and upward when we're catching up, and flat when things are just right.
(Spot checking some of the failures, they seem to mostly be things like connecting to a non-GFiber access point, or connecting on 2.4 GHz when we should be using 5 GHz, both of which should not happen in real life. But then again, those are the sorts of adverse situations where you expect transonic to do better than plain TCP.)
The following is extremely good news. (We still don't have enough data to get a reliable 90th or 99th percentile, but they look promising too, albeit noisy.)
"The errors of a theory are rarely to be found in what it asserts explicitly; they hide in what it ignores or tacitly assumes." – Kahneman
via http://economixcomix.com/home/tpp/, via William.
Sounds like my wifi analytics, essentially :)
"Never spend time trying to stop people from doing stupid things. You should only spend time trying to stop people from doing harmful things."
I’m at the IETF in Seoul.
Korean attendee: Excuse me, could you explain the basic idea behind MPTCP? Is it for when you have two SIM cards, one 3G and one LTE, so you can share the load between the two?
Me: Kind of. You can use it like that, for getting more throughput on cell networks, but mostly I think it’s used for balancing between LTE and wifi networks. Not so much for extra throughput, but for failover, so if your wifi or LTE is connected and not working, it’ll use the other one right away, without having to wait for it to fail first.
KA: [blank look]
Me: Like, sometimes when you you're out of range but it still thinks it’s connected, or when the cell you're connected to loses connectivity for some reason...
KA: [Looks suspicious]
Me: That just never happens here, does it.
KA: Yes, if the connection didn’t work sometimes, people would be very angry.
I learned many things while at IETF in Korea, and I might post more of them if I have time. But the most important one is that I've been brewing my green tea at way too high a temperature.
In most restaurants in North America, when you order tea, they give you hot water and let you choose a tea bag. In Korea, you point at the tea bag and then they select the appropriate hot water.
While at the IETF conference, I showed various people my wifi speed data. One of the things that's been bugging me for a while is that average speed in MDUs (apartments) is higher than the average speed in SFUs (standalone homes), even accounting for signal strength. That is, even at the same signal strength, MDUs go faster on average. This is the reverse of what I'd expect, because MDUs are denser and should presumably have higher levels of interference.
One person at the conference suggested I try breaking down the results by number of attached stations and/or number of nearby APs, with the theory that maybe SFUs have more stations per AP. That gave an important clue.
I also tried breaking down the difference between 2.4 and 5 GHz: that's even more interesting. We can see that SFUs are actually faster on 2.4 GHz than MDUs, and about equal on 5 GHz. Both of these sound about right because 2.4 GHz is more crowded and so more susceptible to congestion in dense MDUs. However, MDUs mysteriously have a larger fraction of devices on 5 GHz than SFUs do, and this is what accounts for the higher average speed in MDUs.
This is pretty mysterious, and applies even if I filter down to only a particular device type (iPhone 6S in this case), so it has little to do with who has more money and can afford newer devices.
But the weirdest thing of all is the plot of 2.4/5 GHz band breakdown vs number of nearby APs. The more APs are visible nearby, the more the fraction of 5 GHz devices drops. It could be my code for counting the number of nearby APs is wrong, although the shape looks roughly right (MDUs have more nearby APs than SFUs). That sounds like a bug. Maybe our 5 GHz wifi (ath10k) breaks more often when more devices are connected to it?
In Korea, they build subway lines really fast. But I'm back in New York now, and I ordered Thai food online, and it arrived at my door in 19 minutes. Priorities, priorities.
So you're thinking I should go via 14th St station?
Technically correct. Still the best kind of correct.
ssh+2FA to all your machines, anywhere, without opening firewall ports.