I’d like to clarify if Interface Queues and FastTrack are compatible with each other?
I’ve been testing traffic between hosts connected to ether1 and ether3 (see conf below). Fasttrack byte counters go up (expected), and I would like to know if FQ-CODEL is working on this setup.
/queue type
add fq-codel-ecn=no fq-codel-limit=1200 fq-codel-quantum=300 kind=fq-codel name=fq-codel
/queue interface
set ether1 queue=fq-codel
set ether2 queue=fq-codel
set ether3 queue=fq-codel
set ether4 queue=fq-codel
set ether5 queue=fq-codel
set ether6 queue=fq-codel
set ether7 queue=fq-codel
set ether8 queue=fq-codel
It’s unclear to me if FQ_Codel does anything without having a max-limit set.
If I set FQ_Codel on to an interface with a queue tree with a max-limit set, it limits traffic. If I just attach FQ_Codel to the wan or any interface, it’s unclear to me if it’s doing anything. It’s unclear to me if FQ_Codel knows to kick in without having a speed set with max-limit. Can it sense back pressure without a max-limit set?
AFAIK, device drivers also need to support BQL. Since it’s just a matter of pretty basic counters, it shouldn’t be too complicated to implement. However, considering that BQL has been around for about 10-12 years, are you absolutely sure they haven’t implemented it already or using some equivalent proprietary flow pacing mechanism required by fq-codel?
Okay, then I suppose they’re using some other type of traffic pacing control required by fq-codel. A potential transition to standard BQL would likely simplify code management in the long run.
OK so, BQL is missing and maybe will be implemented in the future, FQ_Codel needs BQL, this means that using FQ_Codel in queue simple or queue tree is working not in interface queue?
/queue interface set ether1 queue=fq-codel
It doesn’t necessarily have to be BQL, custom-developed queue counters work just as well. Queue managers like fq-codel need these to get real-time information about driver queue length, etc.
Sorry @Larsa for asking again,
do you know if using /queue interface set ether1 queue=fq-codel is “doing something” or it’s like having only-hardware-queue?
This was in one of the change logs for an earlier release. Perhaps, even though this is LTE-specific, this suggests that FQ_Codel can work at line rate with Mikrotik interfaces… as opposed to only when FQ_Codel is added in a queue tree or simple queue?
*) defconf - use “fq_codel” queue as default interface queue for wired ports on LTE devices;