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 don't think I understand this enough to file a good bug report...