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.

> "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 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 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.

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.

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.

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.

In many cases this is actually expected: Some of the SQM algorithms work by “penalizing” some packets and therefore signalling to the sender that it needs to slow down in order to get future packets through successfully.

Those red marks are kind of a “slap on the wrist” that keeps the sender in line.

P.s. Try downloading something that can send to you at 200MBps (and therefore saturate your connection) or something that can receive file uploads at 10Mbps, or do both at the same time and see what that does to the test results.

Bufferbloat isn't when buffers are so full that they cannot accept more traffic; it's when buffers are so big they never get full enough to cause packet drops (the slowdown signal the sender needs), but are big enough that packets spend an unreasonable amount of time waiting in line.

And a good SQM algorithm shouldn't be shooting down packets from a tool like this unless the configured bandwidth limits are really low, because this tool isn't really generating all that much traffic.