DSLReports Speed Test Now Measuring Buffer Bloat

[darkstalker]

500/500 fiber connection from Holland, running on an AC56u with QoS off;

 

[Nullity]

buffer bloat happens both ways but upstream is much more severe hence it gets most of the attention.

Yeah, but the local buffers at the router are probably not contributing to bufferbloat since there is no reason to buffer when going from a slow WAN to a fast LAN.
An upstream hop being operated by your ISP is usually the culprit when bufferbloat is experienced with downloads.

I currently forego any download tweaking since I prefer the extra few % in download speed and the latency to the first hop usually only climbs from ~15ms to ~80ms during a link-saturating download.

 

[Chrysalis]

Yeah but my isp clearly has largish buffers hence the huge change to my downstream bufferbloat.

Note I am on pppoe, which seems bad for this, a guy earlier compared his sky dhcp line to his friend's pppoe line and the latter had bufferbloat.

So I think downstream bufferbloat is probably isp dependent and may also be protocol related.

 

[chamberc]

Mine is through the roof either direct to the modem or through my ac87u. Time Warner, 300/20

 

[Nullity]

Yeah but my isp clearly has largish buffers hence the huge change to my downstream bufferbloat.

Note I am on pppoe, which seems bad for this, a guy earlier compared his sky dhcp line to his friend's pppoe line and the latter had bufferbloat.

So I think downstream bufferbloat is probably isp dependent and may also be protocol related.

I have wondered how much is dependant on the ISP. I am PPPoE ADSL as well (randomly finding "fastpath" improved my ping from ~30 to ~10ms).

I tried to learn about ATM and the up to 7ish(?) stacked layers of encapsulation that graces us with ADSL, but it is just awful. Glad t have what broadband I have though!

If you limit your aggregate download speeds (TCP flow/congestion control) to like 95% of your real-world max, you will avoid your ISP's artificial metering/buffering. My ping never went over 35-40ms, but my downloads fluctuated a few percent, rather than being eerily stable, which I enjoy.

 

[PabloAbonia]

I tried this on Merlin' s 378.54_2 but unfortunately when I switch to traditional, it does not appear to respect the upload and download maximum limits, as DSL reports reports the maximum bandwidth for me: 56/5.

It's an RT-AC56U, with nothing additional running that I would expect to influence QOS.

What is a difference between your fork and Merlin's that could lead to this?

Pablo

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

 

[Chrysalis]

I have wondered how much is dependant on the ISP. I am PPPoE ADSL as well (randomly finding "fastpath" improved my ping from ~30 to ~10ms).

I tried to learn about ATM and the up to 7ish(?) stacked layers of encapsulation that graces us with ADSL, but it is just awful. Glad t have what broadband I have though!

If you limit your aggregate download speeds (TCP flow/congestion control) to like 95% of your real-world max, you will avoid your ISP's artificial metering/buffering. My ping never went over 35-40ms, but my downloads fluctuated a few percent, rather than being eerily stable, which I enjoy.

yeah single threaded downloads have fluctuation without buffer bloat, (probably why isps do the buffering to avoid complaints), in addition if there is any isp side congestion without buffer bloat your speeds will likely get trashed as basically with no buffer bloat your line becomes "polite" and will give up its bandwidth easier. Multi threaded downloads in my testing will still be stable at the rate limit tho. So I am 50/50 on downstream QoS. The best type of QoS for broadband is to prioritize based on packet size, sadly the iptables in 2.6 doesnt support marking based on packet size.

 

[Vandergraff]

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.

Comcast just gave us three free speed upgrades in one - with my download going from 25 - 150 Mbps. I had to disable taffic monitoring by IP to enable hardware acceleration on my RT-N66 (running latest version of John's fork) to get full speed. If I update my router, run Merlins latest version and set adaptive QoS on an RT-AC68 I assume hardware acceleration is disabled. If so what is the maximum throughput of the router (or AC3200) with adaptive QoS (and without hardware acceleration). Still getting an F on bufferbloat

 

[RMerlin]

Comcast just gave us three free speed upgrades in one - with my download going from 25 - 150 Mbps. I had to disable taffic monitoring by IP to enable hardware acceleration on my RT-N66 (running latest version of John's fork) to get full speed. If I update my router, run Merlins latest version and set adaptive QoS on an RT-AC68 I assume hardware acceleration is disabled. If so what is the maximum throughput of the router (or AC3200) with adaptive QoS (and without hardware acceleration). Still getting an F on bufferbloat

View attachment 4443

Adaptive QoS supports NAT acceleration. It's the old traditional mode that doesn't.

 

[Zirescu]

Does anyone know which APP category the VPN traffic falls under the Adaptive type section? I notice that when I enable my VPN routes my download speed pretty much gets chopped to my max upload speed with QOS enabled, but with QOS disabled (and VPN enabled) my download speeds top out at my ISP limits.

 

[RMerlin]

Probably generic TLS/SSL traffic, since the VPN tunnel can use any port, and connect to any remote IPs - so there isn't much for the DPI engine to analyze.

 

[Zirescu]

Yeah, I tried setting each of the app categories to the highest and no change. I did discover a potential bug with some websites getting blocked when I had QOS enabled with the VPN client running. As soon as I disabled the QOS and reapplied the routes I could again access the websites that were getting blocked.

 

[john9527]

As soon as I disabled the QOS and reapplied the routes I could again access the websites that were getting blocked.

Are you using a VPN provider? If so, many sites will block VPN server addresses if they see too much traffic originating from a single address. If you restarted the VPN client, you most likely connected to a different server. This could account for why you were seeing some sites as being blocked.

 

[Zirescu]

Hey John - Good catch. Yes to the VPN provider. It looks like it was the one IP address causing the problem as I retested just now and no issue accessing the same website as before. The VPN client reconnected to a new server after disabling QOS.

On a whim I bumped up my Upload Bandwidth to 27Mb/s (90% of my max download speed) and now when I perform the buffer bloat test (while connected to the VPN provider) my download speeds are maxing out the download speed but the bloat rating drops to a C. If I set it the max upload back to what it should be around 2.25Mb/s, then my download maxes out around 2Mb/s and buffer bloat becomes an A+. When I run the test with the computer not routing through the VPN client on the router I get the max download and max upload speeds and A rating. My download bandwidth was left at 27Mb/s for all tests.

 

[Nullity]

To improve bufferbloat (or properly implement QoS), the device that you control (usually a gateway router) must be the throughput pinch-point/bottle-neck.

Usually, to improve bufferbloat, this rule is applied to egress\upload only, but occasionally rate-limiting ingress/download will further improve worst-case latency (AKA bufferbloat).

Also, according to my tests, the DSLReports bufferbloat test is not accurate (with Chrome on my i3 CPU ArchLinux machine). To test yourself, run download\upload speedtests while pinging Google or similar and see if the RTT fluctuation matches the DSLReports bufferbloat test. For me, DSLReports registers ~160ms while pings registers no higher than ~40ms.

 

[kvic]

Did a quick run on mine. Here is the result:

I'm a bit amazed. The test manages to get the line speed of mine though the test servers are physical far away. Reading its fine prints. It mentions HTML5 multi-stream (I tested single stream too..about the same result) which doesn't require test servers to physically close. What magic is this HTML5 multi-stream?

During download test, network latency (bufferbloat) is near idle latency. Very good. During upload test, as we could see from the graph, it climbs slowly up to line speed. But the network latency increases proportionally with the speed increase. CPU utilization on my AC56U are about the same during upload/download tests.

I don't have HW NAT. No QoS. Using 378.55. Why the difference in download/upload regarding Bufferbloat?

 

[Nullity]

I don't have HW NAT. No QoS. Using 378.55. Why the difference in download/upload regarding Bufferbloat?

Because download and upload traffic are being buffered at different points. Upload is most likely being buffered at your modem, while download is being buffered at some device within your ISP's network.

 

[kvic]

Because download and upload traffic are being buffered at different points. Upload is most likely being buffered at your modem, while download is being buffered at some device within your ISP's network.

That's one possibility. Assume my ISP does not optimise their modem to favour download over upload (their advertised line speed is 100/100), the buffer sizes in the modem shall be same for download/upload. Then download should equally suffer from buffer bloat as we see on the upload?

 

[Yoxxy]

Downstream is slower than speedtest.net; however, more representative of real world performance. There are very few people on my node but I am in MN, so links can get saturated between other Level 3 sites. More so that happens during the work day.

I have HW Nat on but no QoS.

 

[Authority]

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.

Safe to say you won't be adding said "arcane" algorithms to your builds?