Hacker News Reader

Comment by IgorPartola | Hacker News Reader

I tried Clear at one point, thinking I could cut the cord with Time Warner that way. Wi-Max sounds cool on paper, but the latency to the tower was around 30-50ms. This sucks. Browsing the web was not bad, but SSH was a nightmare. Moreover, the latency was inconsistent: 80ms to google.com at one time, 225ms at another. When I talked to the sales rep that sold it to me the plan, he was aware that he had a "ping" in his demo software, but had no idea what it meant. For anyone that wants to try it out: beware their cancellation fees.

View on HN

30-50ms isn't nearly enough latency to make ssh suck. Even 225ms is fine for ssh. You almost certainly were suffering from high packet loss, which means you get spikes of super high "latency" in TCP (because after a couple of packet losses, it holds off retransmitting until some time much much longer than your ping time, so you experience multi-second delays when typing).

Ironically, connections that are sending bulk data (eg. downloads) don't run into this, because a lot of packets get sent at once; if one of them in the middle gets dropped, the recipient knows it right away (because the next one has the wrong sequence number) so it can immediately send an ACK that re-requests the missing one. So on a busy connection, packet loss isn't as big a problem. On an interactive connection like ssh, it's completely deadly and makes it almost unusable.

All that to say: your problem with Wimax is fixable. It's not a latency problem, but nobody has fixed it yet.

Thanks for the reply. Just one clarification: the 30-50ms ping was just to the tower, not to the remote host. It was taking the already slowish ping of 80ms and adding another 30-50ms to it. I think this makes ssh suck since I can see it: 100ms latency == 10 frames per second.

What you were seeing was the dreaded Buffer Bloat. It's really quite common nowadays. Memory is so unbelievably cheap, so device manufacturers all up and down the ISO stack are putting too much memory in their transceiver buffers.

Why is this bad? Because it screws with TCP window adjustments. Remember that your OS will send packets until it starts to see drops, then back off of the transmit rate. You can adjust the parameters (startup rate, backoff rate), but that's the basic principle. However, when there is an overly large buffer somewhere in the middle of the network, this delays drops. This has the effect of making it nearly impossible for your TCP stack to determine the true bandwidth.

For some reason, most mobile device manufacturers are the worst offenders when it comes to bufferbloat.

Anyways, this was a brief summary. For a much better explanation (including pretty graphs), see http://www.bufferbloat.net/

Reply on news.ycombinator.com