DSLReports Speed Test Now Measuring Buffer Bloat

[Chrysalis]

note that the AC66 maxes out at approx 65-70mbit on PPPOE without CTF. If its dealing with heavy threaded transfers it can dip down much lower as well.

When I enable QOS it seems to drop even further down to about 45-50mbit. The net definitely feels snappier with QOS on tho in terms of web browsing, but bulk downloads are slower, so its a give and take for me.

 

[Vandergraff]

For those running my fork (and who like to experiment ), I was able to improve my Bufferbloat score from a 'C' to an 'A' by....

(1) turning on tradition QoS and setting the up/down bandwidth to 90% of rated speed (rest of settings default)
(2) shrinking the send buffer size via an init-start script...

#!/bin/sh

# Adjust TCP send buffer (default is 120832 bytes)
echo 59392 > /proc/sys/net/core/wmem_default
echo 59392 > /proc/sys/net/core/wmem_max

The '59392' value was trial and error and seemed to give the best results for me (YMMV). I have a 50/5 Mbps service.

Also, turning on my VPN service turns things back to 'C' (I did set the sndbuf for the VPN accordingly), but the ping peaks are better than they were before the change.

I am running your latest fork on an RT-N66.

I tried your suggestions above and while I got a marginally better Bufferbloat score (moved from F to D) download and uploads speeds were lower (not surprising given QoS at 90% of previous speed).

When you say experiment with the buffer value is there a range you suggest to try? Are they restricted to specific values? I tried 59392 and 29696. I also tired different devices (Windows PCs, IoS Phone and tablet) to check if the PC was the problem - all the devices gave similar bufferbloat score and speed test score

As above I am on a 25 / 4 connection which normally tests about 30 / 5

 

[dsring]

For those running my fork (and who like to experiment ), I was able to improve my Bufferbloat score from a 'C' to an 'A' by....

(1) turning on tradition QoS and setting the up/down bandwidth to 90% of rated speed (rest of settings default)
(2) shrinking the send buffer size via an init-start script...

#!/bin/sh

# Adjust TCP send buffer (default is 120832 bytes)
echo 59392 > /proc/sys/net/core/wmem_default
echo 59392 > /proc/sys/net/core/wmem_max

The '59392' value was trial and error and seemed to give the best results for me (YMMV). I have a 50/5 Mbps service.

Also, turning on my VPN service turns things back to 'C' (I did set the sndbuf for the VPN accordingly), but the ping peaks are better than they were before the change.

Followed your advice, and BAM....

It went from a 'D' to an 'A+'. Thanks.

 

[Pierino]

Can someone walk me through how to set Qos correctly. I pay for 30 up and 5 down.

 

[Vandergraff]

I tried your suggestions above and while I got a marginally better Bufferbloat score

A little more testing today.

I now think that my download QoS setting is not registering.

Wherever I set it (20 or 25 or 27 Mbps) my download speed continues to be ~30 Mbps and bufferbloat bad.

I can see my upload speed adjusting to different upload QoS settings and also see the upload buffer bloat significantly improve when running the test.

I have an RT-N66 and am running John's fork 374.43_2-11E1j952

 

[john9527]

A little more testing today.

I now think that my download QoS setting is not registering.

Wherever I set it (20 or 25 or 27 Mbps) my download speed continues to be ~30 Mbps and bufferbloat bad.

This is actually expected under ASUS's traditional QoS and the way speedtests are implemented. Traditional QoS is not a 'traffic shaper', and on the download side will always try and use all the bandwidth available. So when you run a speedtest, there is nothing with a higher priority than the download streams and it will run at full bandwidth.

But I'm a bit surprised you see the download test contributing to the Bufferbloat. In all my runs, the download test showed almost no impact on the bloat measurements. Maybe it's due to the slower MIPS processor vs the ARM where I did my testing. If you want to experiment with the receive buffer size as well you can change the receive buffer by changing 'wmem' to 'rmem' in the init-start script (the default value is the same).

I can see my upload speed adjusting to different upload QoS settings and also see the upload buffer bloat significantly improve when running the test.

Upload bandwidth is a 'harder' setting in QoS so I'd expect it to have a more direct effect like you have seen.

I have an RT-N66 and am running John's fork 374.43_2-11E1j952

As a final comment, as you experiment if you go too small with the buffer sizes, you'll eventually get to a point where you can't support your available bandwidths. So if you see things really start dropping off, you know you've gone too far. One set of settings you may want to try is setting both send and receive buffers to 65536.

 

[Haggster]

BTW I realized that the test results are highly dependent on the client device that the test is run from. I've run it from various high end Android devices connected to my RT-AC87 via 5G 802.11ac and they always show some degree of buffer bloat, whereas I now seem to almost consistently get A grades if I run the test from my old ARM-based low-fi Chromebook (802.11n) and especially good results (always A results with minimal buffer bloat values during upload) if I run it from my Core i5 Windows 7 machine. So basically no Android device achieves consistently grade A results, whereas the other two devices do. I've run all tests over wi-fi.

 

[john9527]

It's also different results when using different browsers on the same PC....I'm not sure it's a fully 'baked' test yet....

 

[L&LD]

It's also different results when using different browsers on the same PC....I'm not sure it's a fully 'baked' test yet....

I don't see that as a knock on the test, rather a knock against the browser?

 

[john9527]

I don't see that as a knock on the test, rather a knock against the browser?

Yes and no....if there is a browser dependency they should be up front about the requirements (maybe I just missed it?)

 

[L&LD]

Yes and no....if there is a browser dependency they should be up front about the requirements (maybe I just missed it?)

I see that as a way to weed out the bad examples, rather than wanting a work around for them.

 

[Deleted member 22229]

But I'm a bit surprised you see the download test contributing to the Bufferbloat. In all my runs, the download test showed almost no impact on the bloat measurements. Maybe it's due to the slower MIPS processor vs the ARM where I did my testing. If you want to experiment with the receive buffer size as well you can change the receive buffer by changing 'wmem' to 'rmem' in the init-start script (the default value is the same).

My BB is all on the downstream upstream is ok. As stated at least for me it's not the router as i get the same fail grade even directly hooked to the modem. I am not going to worry about this as it only happens when the connection is at max and that only really happens during speed tests. I also believe the test is accurate because i dont think any other speed tests that i know of constantly sends pings out during the test itself most do it before the actual test begins. Again at least for comcast they say BB will not be an issue once Docsis 3.1 is rolled out sometime in early 2016.

 

[Vandergraff]

But I'm a bit surprised you see the download test contributing to the Bufferbloat. In all my runs, the download test showed almost no impact on the bloat measurements. Maybe it's due to the slower MIPS processor vs the ARM where I did my testing. If you want to experiment with the receive buffer size as well you can change the receive buffer by changing 'wmem' to 'rmem' in the init-start script (the default value is the same).

As a final comment, as you experiment if you go too small with the buffer sizes, you'll eventually get to a point where you can't support your available bandwidths. So if you see things really start dropping off, you know you've gone too far. One set of settings you may want to try is setting both send and receive buffers to 65536.

Thanks - I tried changing send and receive buffers to 65536 (with QoS setting that you recommended before).

Unfortunately that didn't improve the bufferbloat.

I then tried receive buffer at 32768 - bufferbloat still bad but speeds dropped off significantly.

I think at this point I'll have to live with a failing 'F' for bufferbloat...

A shame because I can imagine it might affect us. In our household we can have a couple of people streaming and another playing games at the same time.

 

[crash486]

Speedtests are just depressing if you live in regional/ rural Australia. My download speeds are lucky to reach 2Mbps on adsl2+. Packets are faster via the mail than the Internet!

 

[Chrysalis]

remember as well guys some isps will cause high buffer bloat, cable isp's and isp's who do their own QoS (traffic shaping).

 

[PorscheT]

On my AC56U using Comcast I went from "F" to "A" by just turning on QOS Adaptive.

 

[Ronv42]

I tested with no QOS and Adaptive QOS on my RT-AC87 and results for adaptive QOS look good.

With no QOS:

With Adaptive QOS:

I always run with adaptive QOS but it does go to show that there are benefits if you run applications such as VoIP that are sensitive to jitter and buffering adaptive QOS can resolve it.

 

[dtaht]

I tested with no QOS and Adaptive QOS on my RT-AC87 and results for adaptive QOS look good.

With no QOS:

With Adaptive QOS:

I always run with adaptive QOS but it does go to show that there are benefits if you run applications such as VoIP that are sensitive to jitter and buffering adaptive QOS can resolve it.

I am curious as to what exactly is "in" adaptive QOS these days?

 

[somms]

Shibby's tomato 129 K26ARM USB VPN-64K on my R7000 gateway router over 100Mb/s symmetrical XMisson via Utopia...

BTW: QoS remained DISABLED on the R7000 during testing (I've never had to enable QoS)..

 

[tsunami2311]

QOS On and upload caped at 20mbit

QOS Off

Pay for 100/40 get about 120/40 if QOS is off if on it caped around 105mbit give or take due to cpu cant cope

Side note this test works on the ps4 and says i get 67mbit wireless, yet getting anything off psn i barely hit 35mbit in actual downloads and ps4 own test says 35mbit too, which reinforce my theroy that psn server really are that bad or are throttled