Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - dtaht

#1
24.1, 24.4 Legacy Series / Re: fq_codel console flood
February 24, 2024, 06:16:37 PM
The quantum should be set to the MTU, or about 300 at lower rates if you can spare the CPU.

"Basically once you fill out the queue you will TAIL DROP. If you have a good enough internet connection and your ISP is able to keep up with the traffic on your line the default set limit and tuned quantum can handle it."

While I have not looked deeply at the fq_codel code for freebsd yet, the linux, ns3, ns2 implementations all seek out the biggest queue, and HEAD drop from that. Now depending on how pf is implemented, perhaps it is dropping elsewhere?

Head dropping from the fattest queue is a big feature, however, I can think of numerous ways that could be being done incorrectly - for example linux fq_codel increments the count variable on every overflow so as to hand the AQM more bite against the flow normally.
#2
24.1, 24.4 Legacy Series / Re: fq_codel console flood
February 24, 2024, 06:07:13 PM
I have no idea why you think a quantum of 2400 is good. (I am one of the authors of the fq_codel algorithm).

I started a project recently to try and collect all the complaints about fq_codel and shaping and see if they were a bug in the implementation or not. It was an outgrowth of the reddit thread here:
https://www.reddit.com/r/opnsense/comments/18z68ec/anyone_who_hasnt_configured_codel_limiters_do_it/

So far the openbsd implementation is proving out ok, but I have not had the time, money or chops, to get someone to rigorously test the freebsd (opnsense version) enough to prove to me that it is indeed implemented correctly. Anyone out there capable of running some serious flent tests? I outlined basic tests
to the openbsd person on the case here: https://marc.info/?l=openbsd-tech&m=170782792023898&w=2

I am perversely happy that a probable source of speed complaints about it is it doing too aggressive logging under stress, as reported on this bug here today.

The freebsd bug is being tracked here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276890