bufferbloat drives me crazy

[trustno1foxm]

Hello,
I have a 5G internet and have massive problems when there is a download or upload. I've spent hours reading the forum and trying out instructions without success. I only achieve an acceptable latency when uploading if I enter an FQ-CoDel limit of 5 in the upload pipe... When downloading, I find a good value without the bandwidth being massively throttled downwards. Is there a way to get the values without spending hours of trial and error?
Thank you!

so long

[richb-hanover]

The cake-autorate project (https://github.com/lynxthecat/cake-autorate) aims to solve the problem of bufferbloat on varying links speeds - like a 5G cellular connection, Starlink, or even cable modems that get slow in the early evening.

It works by continually monitoring the available capacity and ping time, and increases the CAKE parameters  to the point that there's a bit of added latency, then backs off.

[bestboy]

Unfortunately, CAKE is not available for Opnsense.
The best we got is FQ-CoDel. It needs a bit of setup, though. Obviously you need to set the pipe bandwidth. It should be sufficient to set it to a value 10% less than the line rate. If your line rate is varying, then try to choose a conservative average rate in the beginning.
In order to get good results, you may also need to set the FQ-CoDel quantum value to your WAN MTU. You can get it from your default route in System > Routes > Status (assuming Path MTU Discovery is working).
Also, setting the FQ-CoDel target for very slow (like mobile) or very fast connections (like fiber) maybe be needed. In order to obtain a target value for your WAN connection, you can use mtr(1). Make sure the line is unused and let it run for a while to get a decent sample count. Use the average ping of the first hop as your target value.

(1) mtr -bz -i 5 -o LSD__NAW__M_X__ -L 55555 1.1

[Seimus]

@bestboy explained it very nicely and actually to the point.

The reason why is this happening is most likely the variable throughput you are getting on your WAN connection. If you have a connection that has a persistent line rate than the problem with latency is less likely to occur.

You need to choose the average BW in the download Pipe you are able to constantly get in order for FQ_Codel guarantee the proper shaping for the proper BW. Also is worth as well to set proper targets.

Another point is, the current implementation of FQ_CODEL is not properly done (not per the desired recommended way of the creators of the algorithm). There is already a BUG report opened on BSD tracker and a email chain between the creator of FQ_CODEL and BSD folks. This current implementation tents to hog the CPU. This as I understand is affecting only a case where there are several flows/streams generated.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276890
https://marc.info/?l=openbsd-tech&m=170782792023898&w=2
https://marc.info/?l=openbsd-tech&m=170785560913124&w=2

Regards,
S.

[trustno1foxm]

Thanks for your answers! The big deal is that the bandwith is varying a lot and when the pipe is set to 100Mbit/s (200Mbit's is peak) I will lose 100Mbit/s, right? Also sometimes it drops to 60Mbit/s depending on the weather. Is there no other way like just check the latency and perform traffic shaping? I really spent hours and played around but without success.

so long

[Seimus]

Thats correct,

If you set the Pipe to 100Mbit/s you will be only able to use 100Mbit/s.

Personally I am not aware of any dynamic configuration of Shaper , FQ_C, depending on current performance of the link.

If you use FQ_C with 200Mbit for BW, it will still perform better when you can hit only half of it than if you have no Shaper at all.

QoS/Shaper are ment to be set to work with the BW and capacity that is persistently available.

Regards,
S.

[bbin]

I've been following Dave Taht's previous post (https://forum.opnsense.org/index.php?PHPSESSID=m3ojpa28lovvbjvj8g6c1eav2o&topic=39046.msg191249#msg191249) and couldn't work out from the bugzilla post if anything ever came of this.  Not sure if franco or others have a sense of what would be required to bring fq_codel performance to parity with Linux.

[Seimus]

Not sure if franco or others have a sense of what would be required to bring fq_codel performance to parity with Linux.

Its already know what is required, Dave did specify it in the BUG report as well the email chain with BSD folks, one of the BSD devs (I presume) implemented and test it. It I believe only needs to be pushed into the code.

If you go thru the BUG report as well the email communication you can see it there.

Regards,
S.

[pfScrub]

There is a system tunable called ECN max retries. I can't find it from my phone. It is generally set to two by default. I like to set it to zero. Seems to help some legacy stuff. You can always run fq codel without ECN too.


Sent from my iPhone using Tapatalk

[pfScrub]

If you can do forensics on device specific TCP connections, SYN proxies on a LAN interface, as opposed to squid proxy, sometimes works well. Allow the firewall to do the TCP.


Sent from my iPhone using Tapatalk