Posted: Thu Dec 01, 2022 17:19 Post subject: Qos settings to mitigate bufferbloat in r7800?
I'm running the latest build of dd-wrt, v3.0-r50963, on my Netgear r7800. I've been playing with Qos settings lately in an attempt to mitigate bufferbloat. I get a C rating on the waveform buferbloat test without Qos. https://www.waveform.com/tools/bufferbloat
.
I have 400/20 cable speed but get about 480/23 on speed tests as Spectrum cable overprovisions. I set Qos to use 420000/19000 with WAN, HTB and FQ_Codel set. 420000 is much lower than the 85-95% dd_wrt recommends but anything higher doesn't seem to help at all.
My problem is, even with these settings, I'll get an A+ rating one minute on the waveform test then wait and under the exact same conditions, run it a second time and the latency spikes as if Qos isn't running at all and I'll be back to a C. More test runs fluctuate between the two.
I've tried FQ_Codel_fast, Pie and Cake and those are worse. Cake used to give me the best results when I had a linksys wrt-1900acs router but on this one it's the worst of all of them.
Anyone have any ideas or advice or should I ignore bufferbloat completely?
Well, the router does not have enough CPU power for ~500Mbit QoS
With such a bandwidth and QoS the processor probably runs with 100% load which is bad for the latency because then the buffers fill up.
You can set "netdev_max_backlog" in the sysctl tab to 120, this helps to keep the latencies low but has other side effects (many dropped packets).
It will be best to use a high performance processor for such bandwidths. (x86)
And the fact that the results in the waveform test change constantly can also have other reasons. (load in the cable network / internet etc.)
Thank you for the reply, ho1Aetoo. I didnt realie QoS didnt work well for higher bandwidth. If I try the "netdev_max_backlog" setting, should I use that with QoS turned off or in addition to it?
And does this mean there is no real way to mitigate bufferbloat with the r7800 and these speeds?
"netdev_max_backlog" is the size of the network packet buffer.
Normally the buffer size can and should be left at ~1000.
But if the processor is running at full load then this buffer fills up and the latency gets measurably worse.
You can then reduce the size of the buffer to 120 ... then you have only a very small buffer and the latency changes only slightly under full load.
But this also has disadvantages, at high transfer rates many packets are dropped (you can see this for example in the WLAN packet info, there are then many errors displayed).
I meant you should test it with QoS turned on.
This could significantly reduce the latency when the processor is running at full load.
But this is not a nice solution ... a nice solution would be to use a sufficiently fast processor.
Last edited by ho1Aetoo on Sat Dec 03, 2022 16:24; edited 1 time in total
This is interesting. Just to experiment, I set QoS to WAN using FQ_Codel, HTB with 430000 down and 19000 up. I also checked all the TCP packet flags.
I looked at the "netdev_max_backlog" setting you mentioned and saw it was set to 2048 by default.
I halved that amount and set it to 1024 with QoS on. Then ran tests. I got A on the waveform bufferbloat test on 8 consecuative tests with speeds over 400mb/s down and 19mbps up.
I then went to https://packetlosstest.com/ and ran tests, some simple and some custom tests I ran longer with larger packets. I noted 0 packet loss.
Was there some reason you suggested such a low number of 120 for the netdev_max_backlog and would you consider 1024 within reason? If the above tests hold, that would seem to be an acceptable tradeoff since my paid-for speed is 400/20.
Well I have already explained it several times, if I explain it to you a 3rd time it will not be better.
and "dropped" packets are not "lost" packets but retransmissions.
and I have also already explained to you why I suggested a small value for you to test
Quote:
"netdev_max_backlog" is the size of the network packet buffer.
Normally the buffer size can and should be left at ~1000.
But if the processor is running at full load then this buffer fills up and the latency gets measurably worse.
You can then reduce the size of the buffer to 120 ... then you have only a very small buffer and the latency changes only slightly under full load.
For Gbit Wan connections increasing the netdev_max_backlog from default 120 to 2000 or even
higher might help (for builds before 44980):
For best throughput:
echo 2000 > /proc/sys/net/core/netdev_max_backlog
For good compromise between latency and throughput:
echo 384 > /proc/sys/net/core/netdev_max_backlog
https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1226060#1226060
