kernel/iptable: fq_codel (fair-queuing) qdisc configuration (possible UDev work?)

[MingcongBai]

Mistakenly opened in AOSC OS Core tree is AOSC-Archive/aosc-os-core#44, describing enabling BBR TCP Congestion Control Algorithm - which is already enabled since the Kernel 4.9 bump in staging.

However, @Artoria2e5 noted that BBR wouldn't be much use - in fact, there might be negative effects if fair queuing (fq) is not enabled in qdisc scheduler (hopefully I did not botch the concept, probably did though...).

With that said, there might need to be a UDev rule in place to set this flag whenever a device is added, command to be uesd is tc - provided by iproute2. A simple example is shown here.

Should this UDev rule be included with our iproute2 package?

[MingcongBai]

A method also described in the same location is to use sysctl.

net.core.default_qdisc = fq

[MingcongBai]

In the end, I appended this to /etc/sysctl.d/02-net.conf provided by aosc-aaa - component of Core:

net.core.default_qdisc = fq_codel

To use fq_codel as default for qdisc.

[MingcongBai]

Test Environment

• University of Wisconsin - Madison.
• 5GHz wireless connection, ethernet-end goes to school internet (unknown carrier).
• Machine is ThinkPad X250 with Intel Wireless 7265AC: 03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59).
  • Machine is unplugged (running on battery).

---

Test Results

Note, I have only posted one of the three tests with the best results in each of the different setups.

Kernel version 4.8.6 (non-BBR), non-fq_codel.

Bufferbloat rating was B, unlike the later two on 4.9.0. Generally unstable latency under load (uploading/downloading).

Original report: http://www.dslreports.com/speedtest/7234452.

Kernel version 4.9.0, BBR, non-fq_codel

Already the latency is quite a bit better, stable on download, but fluctuates a lot when uploading - however there is a increase in upload speeds - over three tests.

Original report: http://www.dslreports.com/speedtest/7234263.

Kernel version 4.9, BBR, fq_codel

Not much different, but there is a significant increase in upload speeds (tested three times, mostly > 180 Mb/s). The 210ms latency on upload test is achieved at an instance during the first ~0.5s (estimated), but mostly dropped to ~30ms later on, never reached over 50ms again.

Original report: http://www.dslreports.com/speedtest/7234694.

[MingcongBai]

Requesting more tests on AOSC OS - Kernel updates should be coming in within one day.

[gumblex]

Is there a difference between fq and fq_codel with bbr?

[Artoria2e5]

For the record, the point of tc-fq is pacing. See main commit at https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f8782ea14974ce992618b55f0c041ef43ed0b78.

It sounds quite normal to only improve upload speed, as congestion control decisions mainly goes to the sender.

[MingcongBai]

Is there a difference between fq and fq_codel with bbr?

"codel" stands for controlled-delay, I guess this is an "improved" version of fq?

[MingcongBai]

It sounds quite normal to only improve upload speed, as congestion control decisions mainly goes to the sender.

Yes, and fq_codel seems to further improve the speed.

[Artoria2e5]

fq_codel is (ugh) basically fq with the codel queue management. Using it with nice congestion controls like BBR may not be necessary, but it certainly helps with ones that don't play as nicely like CUBIC. Codel's official wiki says servers loaded with heavy tcp traffic should use fq instead.

Most of the time BBR behaves so nicely that fq_codel does not need to tell it to stop attempting to send faster like it does with CUBIC.

[MingcongBai]

And... Given the statement "net.core.default_qdisc = fq_codel - best general purpose qdisc", we at least made the reasonable choice...

[Artoria2e5]

Still, BBR officially suggests using fq. The codel part is more or less unnecessary for BBR.

[MingcongBai]

Still, BBR officially suggests using fq. The codel part is more or less unnecessary for BBR.

Right, right. I will make another comparison test in a bit.

[Artoria2e5]

Although technically less taxing on the CPU, fq seems to suffer more from hash collisions: http://blog.cerowrt.org/post/birthday_problem/

[MingcongBai]

Although technically less taxing on the CPU, fq seems to suffer more from hash collisions: http://blog.cerowrt.org/post/birthday_problem/

And should you agree that this makes fq unacceptable as default...

[enihcam]

@MingcongBai how does the fq/fq_codel comparison test go?

[MingcongBai]

@MingcongBai how does the fq/fq_codel comparison test go?

As seen above, fq could potentially have negative effects... So I basically scrapped the idea of making another benchmark.

[MingcongBai]

Fixed with AOSC-Archive/aosc-aaa@6b6543b.