QOS for gaming/bufferbloat improvements

hello, i am looking to optimize/shape my traffic to prioritize my gaming for both upload and download.
any recommendations for which qdisc would be best suited for this ?
my download is 100mbps and upload is 10mbps.
Also to improve bufferbloat as i seen someone able to get his 100+ ping down to around a steady 16ping with the turris omnia

2nd question to my understanding you can only set ingress to kbit/s. what would be the proper conversion for mbps?

3rd: lastly when i go to the qos tab, underneath “enable this qos instance” lists the “interface name” now which interface would i be picking to shape my over all bandwidth? i heard to use qos for your wan port but i dont see a wan option to pick…or does the interface shape traffic by ethernet port(1-5 since turris omnia has 5) any tips ?

1 Like

I would recommend sqm-scripts with layer_cake.qos, please see https://forum.test.turris.cz/t/how-to-use-the-cake-queue-management-system-on-the-turris-omnia/3103/26 and https://lede-project.org/docs/howto/sqm for instructions.

This depends on your link, if your minimal ping RTT is above 16ms, there is no chance in hell for sqm-scripts to improve that (all sqm-scripts does is trying to ameliorate the bad effect of network load on latency, so you can expect RTTs to stick closer to the unloaded reference RTT to a given target with sqm-scripts in spite of loading your network…)

That is easy networking traditionally follows proper SI rules: 1000bit = 1 Kbit; 1000Kbit = 1Mbit; 1000Mbit = 1Gbit…

For the omnia, and modern openwrt/lede versions I believe the rule is that the WAN interface uses the eth1 name. But note if you use VLANs or PPPoE you should instantiate sqm on either eth1.${VLANTAG} or pppoe-wan.

Hope that helps


great advice! and as far as your first response to qos, you are referring to the Queuing Discipline : “cake”: and the queue setup script : “layer_of_cake” correct?

and i believe my minimal ping rtt is around 10/13 , if your referring to the lowest ping ive seen that my link can achieve. but i definitely see the ping spike up to 300ms all the way up to 1000/2000 regularly within the hour which sucks especially when using latency sensitive applications. and mind you this happens when no one is on the network but myself, and its even worse when someone else is.


Yes, that seems reasonable.

Oh, are you using bandwidth hogging programs like bit torrent at that time? I assume you are not, but a suffering from a slightly over subscribed cable segment. That unfortunatelly is not really fixable from sqm-scripts, you could try to see whether shaping to 50% of the bandwidth ameliorates things, if it does you could test whether you can relax that for egress or ingress again, I would hope the ingress at 50% and egress at 85% might actually work reasonably well, but I have not used cable sind early 2013, so I have only an intuition and things might stay bad…

Hope that helps

1 Like

thanks again for replying!
i am not, just streaming things such as netflix is going on which i can see why it would spike my ping. and yes i see what your saying, i am on cable internet and i could see why this would be a thing. especially at peak hours of the day.

i was able to enable regular fq codel or whatever its called and simple for the sqm qos and it seemed to fix 1 of the issues i was having with turris omnia. without any qos enabled , on bufferbloat my ping was always upwards of 300+ and always received an F rating which somewhat explains why i was experiencing a lot of latency. i read around and enabled sqm in startup and enabled qos for fq codel and simple and set download speeds at 93 percecnt and upload to about 90 percent-ish and all readings came back as A’s… now on download bufferbloat is still gets up to the 70ms when under load and thats something hopefully the cake you are suggesting would somewhat help with. as of right now its decent, but possibly it can be improved? idk what do you think should i go ahead with installing cake and then trying out layer of cake and cake? i just don’t know how to work with “schnapps” and make a snapshot of what i have going right now and would have to factory reset everything just in case it messes up :confused: .

So this is easy, all sqm-scripts needs is the correct modules installed and /etc/config/sqm, so just make a copy of /etc/config/sqm before your edits and if you are unhappy, just copy it back and hit save&apply in the GUI again, or log into the router and issue “/etc/init.d/sqm stop ; /etc/ini.d/sqm start”. No need to deal with schnapps for dealing with sqm scripts configurations…

took a shot with these settings (cake, layer of cake) in the que section of sqm qos, and it made the bufferbloat /lag worse. you suggest i switch anything else? i tried playing with the download and upload numbers to try and improve it yet the download bufferbloat is still pretty bad

Do you think “Cake” instead of fq_codel will work with “SImple” que setup script? or are they incompatible. i ask because simple worked ok for the time i used it. and i hear cake is a big improvement over fq_codel

Yes, that should lead to a construct with HTB as shaper and cake as leaf qdisc. In the past I actually tested that and it works, but the more relevant question is should you use it? And the answer to that question is no, this option really only is there for testing it is not expected to lead to something that is better than either HTB+fq_codel or cake/cake.

Well, cake has a few tricks above and beyond what fq_codel offers (especially the deNAT option and the dual-XXXhost isolation modes come to mind), so for a home router cake seems the way to go. BUT if simple.qos/fq_codel performs better in your environment just stick to using it…

Best Regards

what is HTB? sorry so many questions, just very new to this stuff

HTB is the hierarchical token bucket shaper that is used by simple.qos and simplest.qos to restrict the bandwidth (see https://linux.die.net/man/8/tc-htb for a bit more information). We combine HTB to restrict the bandwidth and fq_codel to divide that restricted bandwidth fair between the flows. Cake can perform both objectives and hence does not need to be used with HTB. Simple.qos uses 3 priority tiers/bands and is roughly equivalent with layer_cake.qos, while simplest.qos only uses one priority tier and is roughly equivalent with piece_of_cake.qos.

Hope that helps…


thank you for your response! it is greatly informative and appreciated. feel free to drop any other bits of info/tips you might want to give, still learning as i go and any information would really help me learn this open wrt stuff to further improve my network. i game competitively and anything i can do to reduce the amount of latency on my network would be a1 !

also maybe you can chime in on this and shed some inset on as to why

but when i have cake and peice of cake set in qos, my bufferbloat for download doesnt go past about 35 and for upload it stays at around 0-5ms… now when i use cake/layer of cake the bufferbloat becomes worst? mind you i am using the same ingress and egress numbers for both , im just switching from peice of cake to layer. and on layer my bufferbloat is worst. they say layer of cake is better yet it doesnt perform that way for me… why is that? should i be using different values in ingress and egress?

I take it that by bufferbloat you mean the RTT increase under load? So during the downloading test the latency probes reach base round-trip time (RTT) + 35 milliseconds and during the uploading test base RTT + 5 milliseconds?

Okay, so layer_cake currently uses 3 priority tiers and sorts packets into those based on the DSCP markings. As long as the packets are all marked CS0 there should not be a behavioral difference between piece_of_cake and layer_cake. BUT looking at the DSCP fields comes with a computational costs and cake will in case of CPU shortage tend to increase latency under load while sticking close to the configured shaper bandwidth (while HTB+fq_codel will tend to decrease the bandwidth but stick to the “configured” latency).

So the difference might be realted to incoming packets having weird DSCP markings; you could use tcpdump to capture the data from a speedtest run and look at the packets marking. Wireshark is great to look at the captured packets… Some ISPs in the past mis-labeld packets as CS1 which is treated as background class with high latency tolerance in cake, so if your ISP does that layer_cake is not ideal for your link.

Your router might be close enough to its maximum CPU capacity that the less demanding piece_of_cake still runs well, while layer_cake might already be affected by CPU-cycle shortage. You can log into your router during a speedtest and issue “top -d 1” to get a snapshot of the system load every second; do this during a speedtest with both piece_of- and layer_-cake and look at the first three lines of the output:

Mem: 45008K used, 15400K free, 620K shrd, 5424K buff, 9336K cached
CPU:   1% usr   2% sys   0% nic  95% idle   0% io   0% irq   0% sirq
Load average: 0.00 0.00 0.00 1/69 23918

If the idle value is equal or close to zero you are running out of CPU cycles (typically the sirq value will be rather high).

Could you quantify this a bit, please? Maybe you could post links to the detailed results pages of two dslreports speedtests one with piece_of_cake and one with layer_cake (see https://forum.lede-project.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 for how to configure the dslreports speedtest)

Then “they” are wrong, the difference is mainly in the use of priority tiers by layer_cake, but whether this is good or bad or leads to better or worse performance really depends on your needs; so this is not a question of quality in my eyes, but of policy. So if you are happier with piece_of_cake just use it… (that is there always might be a bug in cake that leads to differences in performance, so if you think you isolated a bug, please keep reporting that, bugs should be fixed :wink: )

No, the bandwidth settings for piece_of_cake and layer_cake do not need to be different (you still might want to set them differently).

Hope that helps