New User - Help Understanding Anti-Bufferbloat

[Rick Froetsch]

Greetings,

 

I understand the general theory and technicals of bufferbloat, and how Duma tries to combat that by reserving X% of your total bandwidth for high-priority packets. I do however have a very specific question that I'm not wrapping my head around. I have a 1Gbps/35Mbps pipe, and real world I can pull 910/32 when unloaded. When running speed-tests from a laptop over 5Ghz WIFI, I expectantly max out at around 400Mbps, however I'm not understanding the bufferbloat results of various tests (DSLReports, Fast.com, etc.) vis-a-vis Duma anti-bufferbloat (ABB). If I set ABB to Never and run one of the mentioned speedtests, I receive latency results of: unloaded 14ms; loaded 600ms. If I set ABB to 70%, pretty much the same, though loaded times to go down a tad. However if set ABB to 70% of 400Mbps, it's only then I can get loaded latency to under 50ms. I don't get why this is, since the laptop can only saturate 400Mbps out of the 910Mbps pipe and therefore what ABB is trying to resolve is already "baked in" by the shear fact that I cannot saturate the Gigabit pipe with a laptop connection alone. Why is this? Why do the 3rd party tests seem relative of what speed I can test at, as I'd expect if I were  to test over 2.4Ghz and capped out at say 50Mpbs of the 910Mbps pipe, I'd have to do 70% of that in ABB to get under 50ms loaded. Shouldn't the ABB settings really only apply to full pipe saturation, say testing hardwired to the Gigabit pipe, and my 400Mbps test should always show under 50ms, all things normal, for both unloaded and loaded? Thanks!

[Netduma Fraser]

Hey, welcome to the forum!

Simply put DSLReports does not get on with our QoS at all and can give false results. The test itself also does not saturate the connection and that is when bufferbloat occurs so it won't give an accurate reading anyway. We usually recommend people follow this guide while saturating their connection and lowering ABB until the ping is as long and stable as possible. Though with your speeds QoS isn't really necessary. Also with 5GHz you should realistically be able to get higher than this, are you in a WiFi heavy area?

http://support.netduma.com/en/support/solutions/articles/16000074717-how-to-test-your-internet-ping

[Rick Froetsch]

Thanks Fraser!

I will keep that in mind about DSLReports; how do you feel about Fast.com? If the results are potentially inaccurate, are they consistently inaccurate and thus valid for testing; I ask because it appeared to follow an exacting pattern of Never = Xms, 70% = Yms, 40% = Zms and seemed therefore measurable, even if results are not "correct" in a singular sense.  I can utilize Pingplotter, I've been a customer for a decade so am very familiar with it. As for the 5Ghz, I am at some distance and -60Dbs so that may factor into the lower reading. This is also my first day on Gigabit, and I'm not entirely convinced I'm getting the 910Mbps consistently, so yet another factor.

However, assuming for the sake of discussion and understanding the concept/intention of the ABB controls, that DSLReports is spot on, my WAN is consistently 910Mbps, laptop capped at 00 Mbps, etc. would I be seeing the results I'm seeing. Where lowering slider to 70% (680Mbps-ish?) and running a laptop that can only pull 400Mbps, would I see high (in the hundreds of ms) loaded/saturated latency or no, it should still read the same as unloaded/unsaturated latency (in the teens of ms)? If I can get this question answered, then that allows every piece to fall into place and I can effectively determine best path and troubleshoot. Thanks

[Bert]

You should test with a wired connection so you actually max out the provider's end, not on wifi so you max out your wifi. 

 

You can get ping spikes as your max out your wifi connection, but these occur between router and your device. So ABB controls do not affect those, unless you go even lower and limit the bandwidth to the device.

 

I have 580/500 bandwidth to my XR500, it supports this but if I walk to the other end of the house I will drop to about 300/300. So it's not very accurate in terms of testing.

 

So answer to your last question, if you set ABB to 680 mbit but test from a laptop using wifi topping out at 400mbit, you will still see ping spikes as your wifi is saturated.

[Netduma Alex]

8 hours ago, Rick Froetsch said:

Thanks Fraser!

I will keep that in mind about DSLReports; how do you feel about Fast.com? If the results are potentially inaccurate, are they consistently inaccurate and thus valid for testing; I ask because it appeared to follow an exacting pattern of Never = Xms, 70% = Yms, 40% = Zms and seemed therefore measurable, even if results are not "correct" in a singular sense.  I can utilize Pingplotter, I've been a customer for a decade so am very familiar with it. As for the 5Ghz, I am at some distance and -60Dbs so that may factor into the lower reading. This is also my first day on Gigabit, and I'm not entirely convinced I'm getting the 910Mbps consistently, so yet another factor.

However, assuming for the sake of discussion and understanding the concept/intention of the ABB controls, that DSLReports is spot on, my WAN is consistently 910Mbps, laptop capped at 00 Mbps, etc. would I be seeing the results I'm seeing. Where lowering slider to 70% (680Mbps-ish?) and running a laptop that can only pull 400Mbps, would I see high (in the hundreds of ms) loaded/saturated latency or no, it should still read the same as unloaded/unsaturated latency (in the teens of ms)? If I can get this question answered, then that allows every piece to fall into place and I can effectively determine best path and troubleshoot. Thanks

The only result that's inaccurate on DSLreports it their bufferbloat rating, the rest is fine. The tricky element is that one is bound to experience packet loss while doing a download test because they're intentionally flooding your connection to push it to its maximum. The PingPlotter test suggested above avoids this by saturating the connection from seperate devices. The way our anti-bufferbloat works is by balancing the usage of multiple devices, so to test it ideally requires the use of multiple devices.

For example, you've got two computers doing huge downloads, and a playstation trying to play online. If you turn on anti-bufferbloat, the two PCs can be prevented from completely saturating the whole network and causing dropped packets. The playstation will get a low latency connection, at the expense of download speed, and the PCs that are downloading will probably experience some packet loss, at least initially while the server sending them packets adjusts to the new setting.

[Rick Froetsch]

Thanks, let me re-word for the sake of discussion so that DSLreports isn't a red herring, as I'm trying to discuss underlying theory of how your anti-bufferbloat works.

Say my WAN in real world pulls 910Mbps, and my laptop on WIFI can only pull 300Mpbs. Your anti-bufferbloat shouldn't ever play a part here correct, since I'm not saturating the true WAN bandwidth? 

[Netduma Fraser]

It depends really on what settings you're using, say you had it at 50% then your max speed via ethernet would be 455 but your PC would still be able to hit its 300mbps limit. It doesn't just throttle when there is saturation detected, it will do this if you enable it.