Now to my question: has anyone with LTE devices + active interface queue “fq-codel-ethernet-default” experienced an improvement over “hardware-only” queue in regards of bufferbloat?
I can’t see nor measure anything helping reducing bufferbloat at all (Chateau LTE12 here). It just makes no difference.
I don’t understand the effectiveness of using fq_codel on interfaces without max-limit set either, and I haven’t figured out how to easily measure whether it makes any difference beyond the anecdotal. Typical speed/bufferbloat tests seem the same for me whether I have interfaces set as fq_codel or left as the default.
From another post on this:
You can change your wan to use fq_codel or even cake directly on the wan interface, but this seems to work only in one direction… egress?.. and I think it’s at the cost of not being able to set a max-limit. I think this may require the development/addition of bql to provide backpressure to allow these queue types to work better at line rate, as opposed to having a max-limit set… It’s unclear to me exactly what fq_codel or cake might do when attached to an interface without max-limit set, but it does seem that routeros is moving toward defaulting some interfaces to fq_codel (wifi? unclear), rather than hardware-only queue types, so perhaps fq_codel at least can provide some benefits without a max-limit set on Mikrotik. Perhaps it still divides things up and tries to service them fairly even without knowing the actual speed limits? I think you’re out of luck using this for the download direction, however, as I don’t think you can attach a queue type to the bridge without using queue trees.