I´m always interested in how people are using cake and fq_codel. We are adding some new features to cake in particular of late.
How´s it working out for you?
The algorithms in cake-autorate could possibly be ported to mikrotik.Please add a built-in 'auto-rate' that dynamically adjusts Cake's settings to match network speeds when LTE/NR congestion fluctuates.
You are very right in that sometimes the internet itself is glitchy. I do keep hoping we will see fq_codel and cake running on more backbone links, but there will always be a glitch somewhere.
Enabling fq_codel or cake indisputably gives me better scores on bufferbloat tests, but it's not always apparent to what degree various queues improve our day-to-day internet use. With or without cake/fq_codel queues enabled, someone will infrequently complain about a loading screen, or dying in War Thunder or FortNite, or a hue light not working, or a video call... but it isn't obvious if it's something a queue can fix. Is it our network, or is YouTubeTV slow or not buffered enough to handle the NFL? Same thing with a video call... is it our side or their side? Is it bufferbloat we can fix with queueing on our end, or just a lack of data from the other side? I don't know how to answer these questions, but queueing (and cake in particular) sounds like an interesting possible solution to setting up the best of all possible connectivity.
I'm currently running cake in a simple queue on eth1 with FastTrack disabled largely because the router (RB5009) can definitely handle doing this at 290/290 and I'm hoping this will eliminate any potential poor performance from our side of the pipe. I run the cake queue as a kind of preventative medicine, even if I'm not sure how to measure its effect on day-to-day internet use in my household.
All this said, it's great to hear that cake is still being developed! I look forward to more best practice discussions on queueing and on future developments.
Good config. I agree with you that if your nearest CDN is less than 30ms away - and you aren´t trying to communicate worldwide, that regional is a good setting.As a home user, my needs are simple, but I wrote up my configuration anyway. It will serve as a report on my experience, and perhaps you will see an error I’ve made and advise me.
I agree with you that if your nearest CDN is less than 30ms away - and you aren´t trying to communicate worldwide, that regional is a good setting.
However, the ack-filter on rx is largely useless and eats cpu. You only need it on tx in your environment.
Are you saying, @tangent, that upload and download settings should be reversed when setting up a simple queue? This wouldn't affect me for speed settings, as I have symmetric, but it certainly would for things like "cake-flowmode=dual-dsthost" versus "cake-flowmode=dual-srchost." If what you cite is correct, I think I have these reversed, and I bet a good number of other users have these settings reversed as well.There is one additional important detail you have to keep in mind: the bandwidth limits are given from the target interface’s perspective, not that of your client. We are used to specifying asymmetric Internet bandwidths like these in terms of the client perspective, but that will give you an upside-down view of the way RouterOS queues work. WinBox will tell you that my “Target Upload” speed is 256M and my “Target Download” speed is 24M, which feels wrong until you realize that when I download something to my client computer, I do so by making the WAN interface upload that traffic to my client.
Are you saying, @tangent, that upload and download settings should be reversed when setting up a simple queue?…the bandwidth limits are given from the target interface’s perspective, not that of your client.
/queue type
add cake-diffserv=diffserv4 cake-flowmode=dual-srchost cake-nat=yes kind=cake name=cake-WAN-tx
add cake-diffserv=besteffort cake-flowmode=dual-dsthost cake-nat=yes kind=cake name=cake-WAN-rx
/queue simple
add comment="RX= Target Upload TX = Target Download" max-limit=950M/95M name=cake-WAN queue=cake-WAN-rx/cake-WAN-tx target=bridge1_WAN
drops are not being counted w/cake or fq_codel. Please feel free to pester tik more about it on my behalf.Are you saying, @tangent, that upload and download settings should be reversed when setting up a simple queue? This wouldn't affect me for speed settings, as I have symmetric, but it certainly would for things like "cake-flowmode=dual-dsthost" versus "cake-flowmode=dual-srchost." If what you cite is correct, I think I have these reversed, and I bet a good number of other users have these settings reversed as well.There is one additional important detail you have to keep in mind: the bandwidth limits are given from the target interface’s perspective, not that of your client. We are used to specifying asymmetric Internet bandwidths like these in terms of the client perspective, but that will give you an upside-down view of the way RouterOS queues work. WinBox will tell you that my “Target Upload” speed is 256M and my “Target Download” speed is 24M, which feels wrong until you realize that when I download something to my client computer, I do so by making the WAN interface upload that traffic to my client.
@dtaht I don't see any drops at all right now, but I'll keep looking. I'm not sure if this means there are no drops to count, or drops are not being counted/kept by the simple queue for fq_codel or cake.
I remain curious as for the reasoning for overriding the default flow mode.
Yes, the chances of being wrong occasionally are very minor. It is better, especially, when inbound shaping, to be using your typical RTT as the estimate so as to get control of the queue before it flows into the isp shaper you are defeating.I agree with you that if your nearest CDN is less than 30ms away - and you aren´t trying to communicate worldwide, that regional is a good setting.
Am I not gambling that my furthest commonly-used CDN is less than 30ms away, and that the consequences of being wrong occasionally are minor?
However, the ack-filter on rx is largely useless and eats cpu. You only need it on tx in your environment.
That's insightful, thanks. I've not only removed that useless bit from the config, I added this paragraph:
"We do this on the cake-tx side alone because in typical cases, we can only control what we send to remote TCP/IP stacks, not what they do in turn. There are exceptions to this, as with a site-to-site WireGuard tunnel, but even in that case ACK filtering has its most useful effect on the narrow side of an asymmetric pipe. Consequently, the best strategy is to do this ACK filtering on each peer’s Tx side alone, improving the remote site’s Rx queuing from afar."
The world seems to have copy/pasted the dual-whatever settings, where, in nat mode, diffserv3 benchmarked out best. dual-whatever does make sense without nat on.I remain curious as for the reasoning for overriding the default flow mode.
Just trying to follow the reasoning, 'overriding' as in any of the examples in this thread?
I am part of the world then. In screenshot above for CAKE I had:The world seems to have copy/pasted the dual-whatever settings, where, in nat mode, diffserv3 benchmarked out best. dual-whatever does make sense without nat on.
Good to know! Thanks for checking in here every now and then, your tips are always very useful.typically you can put cake with the exact, correct, framing hard up against the upload limit (and also use ack-filter there). On downloads, tho, no more than 92%. And thx for playing with rrul!