Hacker News Reader

Comment by apenwarr | Hacker News Reader

Oh neat! If you see occasional red blips, you have probably found a bug (or misconfiguration) in your OpenWRT SQM. gfblip doesn't lie. In fact, I created it to find annoying router bugs like this. If you click the "DNS" checkbox you can find all sorts of terrible router bugs.

It's not too surprising that you don't see latency increase under light load like Youtube. "Under load" really means uploading (especially) or downloading (sometimes) at maximum speed. But Youtube usually doesn't download at maximum speed, because that would imply you can't keep up with its streaming video rate, and you'd get glitches. So your connection is likely not really "under load" at that time. Try uploading a large file somewhere and you should see an immediate change in blips.

View on HN

> "Under load" really means uploading (especially)

In retrospect the industry really got shot in the foot on this ISP bandwidth race. ISP marketing kept going for bigger and bigger numbers but marketing only needs one big number (download speed) to sell subscriptions and so upload speed was de-prioritized leaving us with these wildly asymmetric connections (standard around here is 300/10), but if the upload is saturated (easy to do) the TCP Acknowledge packets can’t make it out and the whole connection grinds to a halt.

In switzerland no one would buy anything else then a symetric connection, normaly it's 1g/1g and for the same price if available 10g/10g

I don't suppose you have any suggestions on what to do about it? I'm now wondering if I should keep sqm off and deal with bufferbloat. I already give up a chunk of my limited bandwidth for it (my connection is only 20mb down / 3mb up).

I don't think I understand this enough to file a good bug report...

I haven't played with OpenWRT SQM for a while, but if it's easy to reproduce with gfblip, it might be a simple matter of telling them your exact SQM settings and the URL to try.

Chances are changing the SQM backend (eg. between fq-codel and cake) will at least change the behaviour and likely make the bug go away.

Thanks! For posterity: I was previously using cake/piece_of_cake.qos. Changing to fq_codel/simple.qos made the blips go away, and seemingly does a better job of eliminating bufferbloat to boot.

fq_codel/simplest.qos made the blips worse instead of better. fq_codel/simplest_tbf.qos reduced but did not eliminate the blips.

I also use OpenWRT with SQM (using cake queuing discipline) on a CM4 Pi to address buffer bloat. I don’t see any red blips, my latency is consistently between 20-40ms on Wi-Fi.

What hardware do you have? SQM is pretty CPU intensive. Mine is just powerful enough to be able to use SQM. Try checking if your cpu usage spikes from softirq interrupts.

I get red all the time in Firefox, chrome is healthy.

I have cake configured on my border router.

so nice to see so many using cake.

that is a dismal ratio. I would set cake to turn on the ack-filter in this case on the upload. Also try comparing cake besteffort with your fq_codel implementation. MOST likely, from your report, you have some higher priority (via diffserv) traffic than blip going, and cake is actually doing the "right thing" by prioritizing that over the test.

What exactly does the DNS checkbox do?

So nice to see gfblip and cake together again at long last.

I'm also seeing consistently spaced red blips.

Same, but only when I go over my companies vpn.

I'm always interested in packet captures of observed misbehavior.

Reply on news.ycombinator.com