Closed MingcongBai closed 7 years ago
A method also described in the same location is to use sysctl
.
net.core.default_qdisc = fq
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
.
03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)
.
Note, I have only posted one of the three tests with the best results in each of the different setups.
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.
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.
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.
Requesting more tests on AOSC OS - Kernel updates should be coming in within one day.
Is there a difference between fq and fq_codel with bbr?
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.
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
?
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.
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.
And... Given the statement "net.core.default_qdisc = fq_codel
- best general purpose qdisc", we at least made the reasonable choice...
Still, BBR officially suggests using fq
. The codel
part is more or less unnecessary for BBR.
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.
Although technically less taxing on the CPU, fq
seems to suffer more from hash collisions: http://blog.cerowrt.org/post/birthday_problem/
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...
@MingcongBai how does the fq/fq_codel comparison test go?
@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.
Mistakenly opened in AOSC OS Core tree is https://github.com/AOSC-Dev/aosc-os-core/issues/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 byiproute2
. A simple example is shown here.Should this UDev rule be included with our
iproute2
package?