The return of Bufferbloat with Gigabit Cable

Post new topic   Reply to topic    DD-WRT Forum Index -> General Questions
Author Message
Fried Chicken
DD-WRT User


Joined: 12 Jun 2019
Posts: 142

PostPosted: Mon Jan 17, 2022 19:15    Post subject: The return of Bufferbloat with Gigabit Cable Reply with quote
Or more specifically, the return of my attempt to combat bufferbloat.

Attempt 1.

Quick summary. After getting Gigabit cable, I encountered insane bufferbloat on my network with my R7000P acting as my router, switch, and WAP.

QoS to solve these issues overwhelmed the CPU at gigabit speeds, so:

I got a ProtectLi FW6 with a celeron processor, a PoE switch, and a bunch of Cisco Aironet 3702i access points that can be had for a song on ebay, flashed with autonomous firmware, and used inexpensively as access points. I do not recommend doing this unless you enjoy networking masochism, as the logic Cisco uses in their products defies common reason and logic.

Thus my network looks like this:

Code:
Arris SB8200 modem --> ProtectLi (DD-WRT) Router/switch --> PoE Switch --> Cisco 3702i WAPs
                                                                   |
                                                                  V
                                              R7000p (dd-wrt) WAP


My main computer is connected to one of the Cisco WAPs.
Ethernet is king; I am a peasant.

Working Bandwidth:

Ethernet: 900/50

802.11ac: 400-500/50

802.11n (5GHz): 250-300/50

Approach to handling Bufferbloat:
1. QoS, 2. TCP congestion control.

QoS Settings:


TCP Congestion Control:


Testing methodology:
dslreports.com/speedtest stopped working for me.
Here’s a new bufferbloat test: https://www.waveform.com/tools/bufferbloat I’m testing on my main computer over WiFi.

With my current settings I get these results

These are really good, however I need better for proper noob ownage in counterstrike, and since I don’t have any actual playing skillz, I need all other help I can get.

Regarding QoS settings, I’m not sure what TCP packets I should prioritize. I was told if I prioritize all of them, it has the effect of not having any QoS? However, small TCP packet handling should still benefit if any UDP crap is going on in the background.

Between the different queuing disciplines, I’ve found that fq_codel works the best for me. I’m not sure why, I’d expect fq_codel_fast or cake to show improvement, but not from my testing. My only guess reasons that the “faster” algorithms are meant for router hardware, and not an intel celeron chip.

It’s a similar story with TCP congestion control. Here are some useful articles. They suggest newer algorithms like cubic or bbr have benefits, and I’m sure somewhere, somehow, they do, but for me I got my best results with westwood from 2001. Go figure.

Now the big thorn in my side:

I can get perfect results if I limit the router’s QoS to below the maximum speed of my Wireless connection. Setting my bandwidth to 300mbps down gives me this beauty.

Well then I can just kill myself. What this essentially means is either: QoS is useless for WiFi or saturating the WiFi link introduces its own bufferbloat independently of the QoS algorithm. Devices connected over WiFi have constantly changing link speeds and that’s the reality of it. If my QoS algorithm implemented on the router can only be as fast as the lowest common denominator,I guess the choice is mine: forego all technology to increase bandwidth in networking, or accept bufferbloat as a fact of life.

Writing this has given me an idea. Possibly bufferbloat is being introduced, not by the local network, but by the WiFi link itself. I hope that’s the case, because then I can limit my bandwidth per device to something my Wi-Fi connection can happily handle, and then enjoy the full benefits of QoS on the router level. I’m going to look into doing this on the device (my computer), since doing this on the network seems stupid, and would mean any automatic dynamic changes would need to happen at the network level, when really it should happen on the device.

Any help is much appreciated. I’ve tried to post as much relevant information as I can so I can get the best possible help, and also help someone else trying the same thing.

One more aside: I’m not sure how reliable switching TCP congestion control algorithms, or queuing disciplines for QoS is on dd-wrt. Although I can’t confirm it, I have the nagging suspicion I have to reboot the router every time I try to change this.



Screen Shot 2022-01-17 at 12.44.20 PM.png
 Description:
TCP Congestion Settings
 Filesize:  29.84 KB
 Viewed:  1101 Time(s)

Screen Shot 2022-01-17 at 12.44.20 PM.png



Screen Shot 2022-01-17 at 12.30.27 PM.png
 Description:
QoS Settings 1/17/22
 Filesize:  82.26 KB
 Viewed:  1101 Time(s)

Screen Shot 2022-01-17 at 12.30.27 PM.png



_________________
Google is Spyware
Sponsor
ho1Aetoo
DD-WRT Guru


Joined: 19 Feb 2019
Posts: 2927
Location: Germany

PostPosted: Mon Jan 17, 2022 19:44    Post subject: Reply with quote
the TCP congestion control on your router only affects TCP traffic that terminates at your router
it doesn't change the forwarded internet traffic at all and only affects connections that are directed to your router itself (for example samba / NAS)

(but I recommend Cubic)

secondly, the QoS settings are tested via cable, since WLAN has its own latency and bufferbloat.

If you fully utilize a WLAN link, the latency will of course also be higher.

However, additional +62ms for 400Mbit throughput is bad.
Fried Chicken
DD-WRT User


Joined: 12 Jun 2019
Posts: 142

PostPosted: Mon Jan 17, 2022 20:16    Post subject: Reply with quote
ho1Aetoo wrote:
the TCP congestion control on your router only affects TCP traffic that terminates at your router
it doesn't change the forwarded internet traffic at all and only affects connections that are directed to your router itself

(but I recommend Cubic)

secondly, the QoS settings are tested via cable, since WLAN has its own latency and bufferbloat.

If you fully utilize a WLAN link, the latency will of course also be higher.

However, additional +62ms for 400Mbit throughput is bad.


I don't get it, what TCP traffic terminates at the router?

Also, what's the difference between QoS on WAN traffic and QOS on WLAN/LAN traffic. DD-WRT won't let me implement both simultaneously, but to my mind it makes sense to do so (traffic shaping on both WAN and LAN connections), no?

Also QoS settings appear at every step of the stack. Client, WAP, Router. Should I be looking at these?

This is where my ignorant stupidity comes in. I don't actually know what's happening under the hood, and I'm just a monkey pressing buttons.


Regarding limiting bandwidth client side. It seems NOBODY does this. To do it on my Mac requires a developer license, and extensive searching to do this in windows gave me a bunch of useless results about throttling background apps. It appears to me everyone is so obsessed with throughput, asking how to limit this is like asking how to make food taste more bland. If only that were true.

I did find this article that heralds from the Windows XP days.

My only option is "Bandwidth limit (%)". It doesn't even explain what that percentage is! I suspect it's based on the negotiation of the adapter: 10/100/1000mbps full duplex for ethernet, or whatever the link rate is for WiFi. This is just my guess though.

Putting in 32%, a number I pulled out of my ass, gave better results, but still not as perfect as what I got when limiting QoS on the router:

https://www.waveform.com/tools/bufferbloat?test-id=ae3a623f-6756-4cca-a2b1-d5a073a11fb1

_________________
Google is Spyware
ho1Aetoo
DD-WRT Guru


Joined: 19 Feb 2019
Posts: 2927
Location: Germany

PostPosted: Mon Jan 17, 2022 20:20    Post subject: Reply with quote
I have already added this in the meantime in my previous post


ho1Aetoo wrote:
it doesn't change the forwarded internet traffic at all and only affects connections that are directed to your router itself (for example samba / NAS)


For forwarded Internet traffic, the router setting is less valid.
This is where the congestion control of the server and client comes into play.
Fried Chicken
DD-WRT User


Joined: 12 Jun 2019
Posts: 142

PostPosted: Mon Jan 17, 2022 20:34    Post subject: Reply with quote
ho1Aetoo wrote:
I have already added this in the meantime in my previous post


ho1Aetoo wrote:
it doesn't change the forwarded internet traffic at all and only affects connections that are directed to your router itself (for example samba / NAS)


For forwarded Internet traffic, the router setting is less valid.
This is where the congestion control of the server and client comes into play.


Got it. Between TCP congestion algorithms, I saw mention of compatibility between devices. What differences would I then see? Faster LAN connections, say using Screen Sharing on the LAN between my Macs, or transferring files to my old WDTV acting as a NAS? Or will I not see anything, since my network is relatively dormant.

_________________
Google is Spyware
ho1Aetoo
DD-WRT Guru


Joined: 19 Feb 2019
Posts: 2927
Location: Germany

PostPosted: Mon Jan 17, 2022 20:46    Post subject: Reply with quote
Neither, this only applies to TCP applications that run directly on the router, for example if you use the router itself as a NAS.

As mentioned, the server and client are responsible for congestion control.

dd-wrt with samba server <---> client

or

dd-wrt WebIF <---> client

If you use your WDTV as NAS, the server is the WDTV.

Each device has its own congestion control - default for most devices is Cubic (but in case of doubt you have to check)
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> General Questions All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum