DSLReports Speed Test Now Measuring Buffer Bloat

[Vandergraff]

Anyone else tried the new DSLReports Speed test

http://www.dslreports.com/speedtest

Seems to work pretty well.

On a 25/4 Mbps Comcast connection I get this result.

Other speed tests confirm the connection speeds but the DSLReports test is grading my connection F for buffer bloat.

I am using an RT-N66U running John's 'Merlin fork 374.43_2-11E1j9527'

From Merlins post here it sounds like 'Buffer bloat can be introduced at any point along the route'

Technical Introduction to Bufferbloat

Buffer Bloat FAQ

Would be interesting to see what results others are getting.

Its only when something gets measured (and reported) that the industry tries to find ways to improve the score....

Thanks

 

[cosmoxl]

I'm over VPN and still got an A grade for bufferbloat.

 

[Deleted member 22229]

It's not your router it's Comcast I ran this test and got a failed grade for buffer bloat then unhooked the router and wired straight to the modem and still failed the BB test. This happens to most on Comcast but not every one. Comcast is also aware they have this issue and say they are working on a fix probably won't be addressed till docsis 3.1 is rolled out. This problem with BB is only a issue when you max out your connection normal web activity is still ok.

 

[Rich Brown]

It's not your router it's Comcast I ran this test and got a failed grade for buffer bloat then unhooked the router and wired straight to the modem and still failed the BB test. This happens to most on Comcast but not every one. Comcast is also aware they have this issue and say they are working on a fix probably won't be addressed till docsis 3.1 is rolled out. This problem with BB is only a issue when you max out your connection normal web activity is still ok.

Comcast has done great work to specify an algorithm (called PIE) that helps bufferbloat. But if you're using a Comcast router and modem combination, you're probably stuck until they roll out the DOCSIS 3.1 upgrades (unknown time frame, as of May 2015).

Note: your computer can be bloated as well - that could explain why it happens when you connect it directly. Bufferbloat has to be fixed everywhere. That's why it's so attractive to control bufferbloat in your router: it can handle all the equipment in your house at the bottleneck.

If you have another router that can run OpenWrt firmware, the fix is straightforward. Install OpenWrt, then the luci-app-sqm package as described at http://wiki.openwrt.org/doc/howto/sqm and you'll be on the air.

If your router won't run OpenWrt, you should see if it can support the "fq_codel" qdisc - that's the "magic" for solving the problem. (And to learn more about Bufferbloat, check my blog, http://richb-hanover.com/bufferbloat-and-the-ski-shop/ )

 

[RMerlin]

Adaptive QoS + my down/up rates set to roughly 90% of the maximum rate (I have 30/10 cable):

No need for special arcane algorithms.

 

[MarioCaires]

Nice alternative to speedtest! It seems reliable...

Talktalk 60/20

 

[Deleted member 22229]

Adaptive QoS + my down/up rates set to roughly 90% of the maximum rate (I have 30/10 cable):

No need for special arcane algorithms.

Yep that's the fix for now and it woks well.

 

[john9527]

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.

 

[L&LD]

john9527, i only tried your option 1) for my 50/10 (actual 53/11.75) DSL connection on my RT-N66U and have seen a huge increase in how response all my devices on my network now are when they're accessing the 'net.

The speedtest shows no change in bufferbloat, but the download speed from a far off location is almost double at about 45Mbps.

Thank you for getting me to try this. +1

 

[easyriider]

With this speedtest I have bufferbloat C but also a very high ping. On a local speedtest there is no bufferbloat result, but the ping is 1 ms.

(40/4 cable connection)

 

[Chrysalis]

sadly my ac66u cant manage my net speed if I enable QoS so I have to put up with bufferbloat :/

 

[highwire]

This is a RT-AC87U connected to a Cisco DPC3848 in bridge mode. I measured it on my MacBook Pro over wireless. The RT-AC87U has no QoS/Trend Micro stuff enabled, and CTF acceleration enabled. My connection is rated at 100Mbps down and 10Mbps up.

 

[Pierino]

When I run this test my result looks nothing like the ones posted here. I don't even get a bufferbloat result.
I used the link posted above.

 

[highwire]

When I run this test my result looks nothing like the ones posted here. I don't even get a bufferbloat result.
I used the link posted above.

Click on the green "Results and Share" button.

 

[Deleted member 22229]

This is a RT-AC87U connected to a Cisco DPC3848 in bridge mode. I measured it on my MacBook Pro over wireless. The RT-AC87U has no QoS/Trend Micro stuff enabled, and CTF acceleration enabled. My connection is rated at 100Mbps down and 10Mbps up.

Not all areas are affected by BB and again this condition is only a issue when your connection is maxed out. 99 % would never notice it. That said it is a problem and at least for cable it will be fixed with docsis 3.1 roll out coming soon.

 

[DaveLessnau]

I'm thinking of giving this a try, but I'd like to make sure of a few things first:

1. If I turn on QoS, that will turn off HW Acceleration on my RT-AC66U. Since my Cox Preferred plan theoretically only delivers 50/5 (though my actual is 60/6), I assume there won't be any decrease in speed from the loss of HW Acceleration.

2. I should set my down/up rates to roughly 90% of the theoretical maximum rate (50/5 -> 45/4) and not 90% of my usual actual rate (60/6 -> 48/5). Of course, we're talking a minuscule difference here.

EDIT: I went ahead and turned on QoS @ 45/4. I see a microscopic improvement at both Speedtest.net and DSLReports.com (BufferBloat is still a C). But for all practical purposes, there's no difference. Not a complaint, mind you. I'm still perfectly happy with the router and the Merlin firmware.

 

[Pierino]

I've never messed with Qos. I've got an rt-ac68p running RMerlin's latest.
I pay for 30mbps down and 5 up.
If I set my download to 27mbps using adaptive Qos, when I run my speed test I get 3mbps. With out Qos set I get my full download speed.
I'm sure I'm doing something wrong.

 

[john9527]

EDIT: I went ahead and turned on QoS @ 45/4. I see a microscopic improvement at both Speedtest.net and DSLReports.com (BufferBloat is still a C). But for all practical purposes, there's no difference. Not a complaint, mind you. I'm still perfectly happy with the router and the Merlin firmware.

With the AC66U you only have traditional QoS available, not Adaptive which relies on the TrendMicro DPI engine. I'm sure you've see that enabling QoS, has disabled HW Acceleration, but on the AC66U you should be OK up to about 150Mbps w/o the acceleration.

I'm on the same Cox plan you are, and didn't get the improvement in the Bufferbloat score until I also shrank the send buffer. I think the way that Cox does it's upload bandwidth limiting is really driving things crazy, and shrinking that buffer helps smooth things out. But, as been said, I don't think you would really see an effect without having uploads (like serving torrents) active at the same time as a timing sensitive app like gaming or VOIP.

 

[sfx2000]

Be happy you can even reach the DSLReports speedtest site...

Cox did some kind of maintenance on their network last night in San Diego (5/21), and the entire DSLReports site is now unreachable from my local broadband connection...

I can VPN into the office, and we get there just fine...

The maint also broke other stuff on my network (work vpn bind, he.net IPv6 tunnel, and a dyndns end-point) - spent most of the morning getting that all sorted and back up..

angry eyes at cox - this is the second time in about 6 weeks this has happened...

------------

$ ping www.dslreports.com
PING www.dslreports.com (64.91.255.98) 56(84) bytes of data.
^C
--- www.dslreports.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5040ms

$ traceroute www.dslreports.com
traceroute to www.dslreports.com (64.91.255.98), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.452 ms 0.420 ms 0.445 ms
2 10.143.0.1 (10.143.0.1) 11.256 ms 15.143 ms 16.115 ms
3 ip68-101-128-8.sd.sd.cox.net (68.101.128.8) 16.095 ms 17.360 ms 17.340 ms
4 68.6.11.202 (68.6.11.202) 45.133 ms 46.216 ms 46.167 ms
5 sanjbprj01-ae0.0.rd.sj.cox.net (68.1.5.184) 35.462 ms 36.714 ms 36.697 ms
6 68.105.31.45 (68.105.31.45) 28.751 ms 68.105.31.39 (68.105.31.39) 24.463 ms 23.123 ms
7 he-5-1-3-cr01.sunnyvale.ca.ibone.comcast.net (68.86.86.209) 30.933 ms * be-16-cr01.sanjose.ca.ibone.comcast.net (68.86.83.41) 34.856 ms
8 be-10910-cr01.sunnyvale.ca.ibone.comcast.net (68.86.86.101) 24.339 ms he-0-15-0-0-cr01.denverqwest.co.ibone.comcast.net (68.86.89.138) 55.783 ms be-10910-cr01.sunnyvale.ca.ibone.comcast.net (68.86.86.101) 25.558 ms
9 he-0-3-0-2-cr02.denver.co.ibone.comcast.net (68.86.85.193) 54.410 ms he-0-3-0-5-cr02.denver.co.ibone.comcast.net (68.86.86.205) 66.208 ms he-0-4-0-9-cr02.denver.co.ibone.comcast.net (68.86.86.197) 64.831 ms
10 he-0-4-0-9-cr02.denver.co.ibone.comcast.net (68.86.86.197) 66.050 ms be-10617-cr01.350ecermak.il.ibone.comcast.net (68.86.85.169) 76.505 ms he-0-3-0-3-cr02.denver.co.ibone.comcast.net (68.86.86.121) 52.360 ms
11 be-10617-cr01.350ecermak.il.ibone.comcast.net (68.86.85.169) 71.951 ms 75.848 ms 77.144 ms
12 he-0-16-0-0-pe03.350ecermak.il.ibone.comcast.net (68.86.88.146) 73.232 ms * 50.242.150.130 (50.242.150.130) 73.011 ms
13 lw-dc3-core1-te8-16.rtr.liquidweb.com (209.59.157.244) 79.494 ms 81.335 ms *
14 lw-dc3-dist16-po5.rtr.liquidweb.com (69.167.128.93) 79.962 ms lw-dc3-core1-te8-16.rtr.liquidweb.com (209.59.157.244) 79.900 ms lw-dc3-dist16-po5.rtr.liquidweb.com (69.167.128.93) 81.182 ms
15 * * *
16 * * *

29 * * *
30 * * *

 

[Haggster]

I'm thinking of giving this a try, but I'd like to make sure of a few things first:

1. If I turn on QoS, that will turn off HW Acceleration on my RT-AC66U. Since my Cox Preferred plan theoretically only delivers 50/5 (though my actual is 60/6), I assume there won't be any decrease in speed from the loss of HW Acceleration.

2. I should set my down/up rates to roughly 90% of the theoretical maximum rate (50/5 -> 45/4) and not 90% of my usual actual rate (60/6 -> 48/5). Of course, we're talking a minuscule difference here.

EDIT: I went ahead and turned on QoS @ 45/4. I see a microscopic improvement at both Speedtest.net and DSLReports.com (BufferBloat is still a C). But for all practical purposes, there's no difference. Not a complaint, mind you. I'm still perfectly happy with the router and the Merlin firmware.

Capping everything at 90% might be effective, but you might also sacrifice too much of your actual downoad bandwidth, which is the most important one for most people. Try running around ten speedtests while your network is quiet, preferably via Ethernet (wifi should be fine though, as long as it's not crowded in your place and might distort the results). Then check what the average maximum of that is and set the bandwidth cap in QoS to that value minus one mbit. Do the same for your upload bandwidth and set it to 80% of the average maximum.

According to my experience buffer bloat mostly affects upload traffic, so setting it to 80% of the real maximum you're getting, might give you way better results. On the other hand your downloads won't get slowed down that much and will stay very close to your real-world maximum while still ensuring that the buffer won't be full. If you got the time just try it and compare it to your current settings.

My connection is rated 20up, 100down - I set my QoS limit to 15up, 96down and get very good results with mostly grade A buffer bloat values while keeping almost all of my real-world maximum download bandwidth.

After running several tests I found this to be the best setting in my case. Funnily enough further limiting the upload bandwidth even made the buffer bloat values become worse. I also played with the buffer sizes a bit but set them back to their default values after getting the impression that the modified values made the result become worse instead of improving them.

With QoS disabled the buffer bloat values are in deep red, consistently (almost only during upload though)

(using the AC87 btw)