In this edition of Actual Words Used in Avery's performance review:

tone, unflinching, rash, tension, critical, not politically smart, more diplomatic, direct, brash, aggressive, friction, undercut, abrasive, not respectful, more constructive

Good news however!  This time they were all in the "things to improve" section.  Previously words like that had been mainly relegated to the "strengths" section, which I assume was for fear of retaliation. Conclusion: fewer people than previously are afraid I will kill them. That sounds like progress to me.

As usual, thanks to everyone for their awesome and thoughtful feedback. :)

Today I learned that decent wifi + good connection to gigabit server in  Europe + TCP = maybe 10 Mbits/sec or less.

Assumptions about the delay-bandwidth product strike again.

The world has a lot of fundamental operating system work ahead of it before people actually get a gigabit all over the Internet.

Kind of awesome.  And yet I fear that we're going to be stuck in a world where Net Neutrality isn't legally mandated, so maybe we ourselves have to be the ones to show how not to suck at it.

Pretty good commentary on the debate around systemd: http://www.landley.net/notes.html#23-04-2014

I am not able to rightly comprehend the chain of events that led to this error message being composed.

If nothing else, I'm now convinced of the teaching power of animations.  I always wondered how that works, and now I know, in about two seconds.

My sister got married.  My dad built a tardis.  I think you can infer the rest.

Visualizing network traces:

I'm trying to get some code going that will allow you to easily obtain and upload a network or wifi capture, and then let people like me visualize and analyze it (and hopefully someday, analyze it automatically).  I'm a few steps away from that, but here's an early example.  This is a TCP trace, so it doesn't have any of the wifi bits in it yet.  It uses afterquery and dygraphs.

This combines the basics (possibly still buggy, oops :)) of a visualization method by Tim Shepard, which is simply to plot the cumulative bytes transferred (ie. current sequence number) of a TCP session on the Y axis, against time on the X axis.  On top of that, we have a shaded area where the bottom is the bytes ACKed by the other end, and the top is that amount plus the rwin size, showing how much of the window the transmitter is currently using and how much it has left.

With that, I combined a view inspired by digital logic analyzers, with a bunch of narrow strip charts all sharing the same X axis (but totally different Y axes), stacked vertically.  With a large number of traces, this is easier to view than plotting them all on the same chart.  So where Tim could plot a single TCP session at a time, this tries to show you them all at once and how they compare over time.

I think the results are pretty neat, albeit not super useful yet.  Tim's original visualization can point out things like TCP retransmits, duplicate ACKs, and SACKs, which are key to analysis.  Also, just a few minutes of sniffing a network connection gets you a ton of tiny little useless TCP connections in addition to the interesting ones, causing a profusion of uninteresting graphs that blot out the interesting ones.  On the other hand, I think this technique will be pretty good when visualizing wifi traffic, since I can plot eg. wifi sequence numbers on one chart, RSSI on the next, MCS on the next, retry count on the next, and so on.  I just need to write more code to dissect wifi headers.

Using afterquery and dygraphs for this may have turned out to be a mistake.  This sample plot is only 60 seconds worth of a very slow (3 Mbit/sec) Internet link, and the system is already kind of bogging down.  Ironically it's not the number of packets, though, it's mostly just the HTML renderer sitting around laying things out, according to Chrome's profiler.  That doesn't really make sense since it's just a bunch of rectangular fixed-size canvases.  But throwing all this away and plotting directly onto a single canvas would probably go a lot faster.

More network packet visualization, this time with wifi.

It's interesting to zoom in on the 'seq' (wifi packet sequence number) graph and compare it to the 'mcs' (modulation/coding scheme number, roughly corresponding to transmit rate) graph directly beneath it.  You can see some packets get transmitted, then they get retransmitted (sequence numbers repeat), and it still didn't work so it backs off to a lower rate.

This is the TV box 1.0 doing the transmitting.  I believe it has particularly bad rate selection, so I think this is an example of doing it "wrong", but I can't quite say that for sure because I'm only just now finally able to graph this stuff and I haven't seen a "good" transmitter yet.

In other news, RSSI was -65 or so even from about 8 feet away.  The TV box is mounted behind a TV, but still... pretty sad signal strength.