You are not logged in.

#1 2017-12-24 23:21:55

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 1,180

Changing the congestion control algo used in Bunsenlabs ( Debian. )

Not going to get into what or why mess with your congestion control. Plenty of info available on the topic. Gnu/Linux has had pluggable control algo's for quite some time. I wanted to switch from the default, which majority of the time will be Cubic to the Veno control algo. Cubic is well tested, been around a long time and is known to work well in many/most situations. However I'm on a laptop and using a lossy wireless connection and some algo's are known to work well in whichever given situation.

Veno is supposedly optimized for such a situation. Ok so in this babble tute, I'll be covering that but the same will work with any of the others too. Let's start out by seeing which are available on the gnu/Nix OS. To do so run ...

ls -la /lib/modules/$(uname -r)/kernel/net/ipv4

Example output, we're looking for all the junk with tcp in it.

-rw-r--r--  1 root root  7216 Nov 22 18:38 tcp_bic.ko
-rw-r--r--  1 root root 10000 Nov 22 18:38 tcp_cdg.ko
-rw-r--r--  1 root root  7040 Nov 22 18:38 tcp_dctcp.ko
-rw-r--r--  1 root root  4384 Nov 22 18:38 tcp_diag.ko
-rw-r--r--  1 root root  4724 Nov 22 18:38 tcp_highspeed.ko
-rw-r--r--  1 root root  6828 Nov 22 18:38 tcp_htcp.ko
-rw-r--r--  1 root root  5220 Nov 22 18:38 tcp_hybla.ko
-rw-r--r--  1 root root  6040 Nov 22 18:38 tcp_illinois.ko
-rw-r--r--  1 root root  5828 Nov 22 18:38 tcp_lp.ko
-rw-r--r--  1 root root  8088 Nov 22 18:38 tcp_nv.ko
-rw-r--r--  1 root root  3904 Nov 22 18:38 tcp_scalable.ko
-rw-r--r--  1 root root  7240 Nov 22 18:38 tcp_vegas.ko
-rw-r--r--  1 root root  4832 Nov 22 18:38 tcp_veno.ko
-rw-r--r--  1 root root  5208 Nov 22 18:38 tcp_westwood.ko
-rw-r--r--  1 root root  5196 Nov 22 18:38 tcp_yeah.ko

Also note: Control algo's that are actually compiled into the kernel won't appear here, nor in lsmod etc. One of interest is the BBR algo. I've got it and a couple others compiled into my kernel. Ok so in the list above I see Veno, the one I'm interested in. Next to edit a file as root/sudo, I open the following, I'm using the leafpad editor here, of course use whatever you prefer. In run dialogue in this case.

gksudo leafpad /etc/sysctl.conf

When the file opens, scroll to the bottom and added the following.

# Trying out the veno congest control, supposed to be geared for wireless nets.
net.ipv4.tcp_congestion_control=veno

Clearly you would substitute the control algo you want in place of veno.

Edit: This step(below), the part in quotes/bold isn't necessary. I removed it(tcp_veno module)suspecting that with the Veno algo set in /etc/sysctl.conf that it'd load without this, removed it from the below file, rebooted and yep, "lsmod |grep tcp" does show tcp_veno module loaded without being in any file. Still keeping this here for the heck of it anyway. It's still interesting, poss useful to know and wouldn't have hurt anything.

Ok next up editing another file, this time in terminal for da heck of it, only real difference is I tend to add an &exit to the end of the command so that the terminal runs whatever and then closes itself, rather than staying open.

gksudo leafpad /etc/modules-load.d/modules.conf &exit

And I added the kernel module for veno so that it's loaded at boot, the "tcp_veno" below, as shown in the file, one module per line for any modules you want loaded.

# at boot time, one per line. Lines beginning with "#" are ignored.
tcp_veno

Ok reboot and that's pretty much it. Though just to be detailed oriented(anal) I check to see which algo is in use with ...

cat /proc/sys/net/ipv4/tcp_congestion_control

Sure enough output returns veno and also same thing, check to see it's module is loaded ... which also returned what I wanted, telling me that tcp_veno is loaded.

lsmod |grep tcp

Last edited by BLizgreat! (2017-12-25 09:23:17)

Offline

#2 2017-12-25 00:31:34

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 1,180

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

Btw: Which I haven't even bothered doing any connection speed tests, haven't noticed any great improvement between Veno vs Cubic anyway. Still though, something else people can mess with in the never ending effort to optimize.

Last edited by BLizgreat! (2017-12-25 00:59:59)

Offline

#3 2017-12-25 07:37:22

ohnonot
...again
Registered: 2015-09-29
Posts: 4,129
Website

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

yes it would've been nice to hear that it actually helps with speed.

anyhow, thoughts:
if all those modules are present on the machine, doesn't that imply that they are there to be used? by something? maybe a wireless driver saying: hey, i provide an internet connection, let's switch to veno?
also: what about ipv6?

Offline

#4 2017-12-25 08:31:24

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 1,180

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

^Haven't performed any real testing as of yet. Only switched to it last night and yeah the pluggable thing wasn't done without reason surely. As with everything gnu/Linux we've been given no shortage of options, it's up to each nixer and their particular usecase/situation to decide what's best. There's plenty of benchmarks floating around the webz that do show one can be superior to another.

This is yet another subject not overly well covered online from what I've seen, that being how to switch em. There's enough information on it and more than enough on the overall topic of what congestion control is etc. Associated subjects like tuning the gnu/Linux Tcp/Ip stack, use of /etc/sysctl.conf etc. Haven't really gotten far as to that though, beyond research and reading.

Same for ipv6, don't really know all that much about it. Read here and there, somewhat understand this n that about it but mucho to learn. For a long time it was a moot point, as ipv6 hadn't been rolled out to any great extent. That's changing/changed as it's being adopted and deployed en masse now. So yeppers, it's probably time to take more interest in it as ipv4 ip addresses getting exhausted and so many more devices joining the webz. The capacity of endless ip addresses ipv6 offers is nutz.

Every friggin device on the planet from android phone, to smart watches can apparently each have it's own ip address with the thing ! Arghhhh. There is an ipv6 directory in Stretch (and earlier Os's too) located here /proc/sys/net/ipv6/ Very lil ... more like no idea wth any of it does though. Which btw kinda worries me.

Vll! smile

Last edited by BLizgreat! (2017-12-25 08:38:16)

Offline

#5 2017-12-25 08:49:28

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 1,180

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

Dang also reason(s) Cubic was chosen as default. Sucker no doubt does a good job and if/when any of the others surpasses it's hands down, then people among the uber-geekdom will start discussing that fact. As will x-distro(s) maintainers no doubt. Though in x-situation, yep ... one could be a better choice vs Cubic or xyz-algo and you can easily switch between them, some more complicated than others. ie: The BBR algo, not as simple as the instructions above. Anybody curious should google it, ironic ... considering Google's the one's behind the thing.

Last edited by BLizgreat! (2017-12-25 08:53:03)

Offline

#6 2017-12-25 12:59:40

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

I thought congestion control was for servers running on the system, is that not the case?


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#7 2017-12-25 17:13:53

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 399
Website

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

Exactly. It can help only if you upload a lot of data. It only works at the sender, not the receiver.

Offline

#8 2017-12-26 08:03:22

ohnonot
...again
Registered: 2015-09-29
Posts: 4,129
Website

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

^ i guess you're right in the end, but what i could find about the topic, it never clearly states that.
the wikipedia article is most outspoken with a single word:

Network protocols that use aggressive retransmissions...

all others just talk about it as if it was clear what it's there for...
http://sgros.blogspot.fi/2012/12/contro … ntrol.html
http://linuxgazette.net/135/pfeiffer.html

i guess even on a desktop (non-server) system there can be scenarios where congestion control is needed.

Offline

#9 2017-12-26 10:36:32

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 399
Website

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

Wikipedia is not a reliable source of information on TCP, due to the complexities and the ever-changing nature of the protocol. If you want to learn about it, I recommend the relevant chapter from "Computer Networking - A Top-Down Approach" by Kunrose. The reading difficulty is not much worse than Wikipedia, as it's a textbook for undergrad students.

If you want to go "to the source", Jacobson's article http://ccr.sigcomm.org/archive/1995/jan … cobson.pdf is the original proposal on TCP congestion control, but it's quite a lot of math.

Offline

#10 2019-10-26 08:00:49

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 1,180

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

Mostly pointless update:

Yep, still know there are valid uses for a change of congestion-algo. Surely the geeks who took the time to create them, did so for quantifiable reasons. Again ie: Cubic does a good job for sure, though if someone is on a lossy wireless connection and there's algo's supposedly specifically designed for that usecase, why not give it a try. Certainly easy enough to switch/change them. Some more complex than others though.

Example scenario: Atm I'm riding a neighbors (about 20-25 feet)through a couple walls and what nots wireless. Hopefully will get around to trying some of these algo's meant for lossy wireless. Though yeppers, am soon going to just go ahead and get dedicated highspeed fellows.

More to it too of course, lofty words such as network topography come into play. As well as junk like this. Not a one size fits blahblah. smile

Offline

#11 2019-11-14 10:09:44

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 1,180

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

Just wanted to mention a package and possible interesting use people could put it to. It's in the repo's and is called speedtest-cli. Is a command-line tool for doing what it's name suggests. Read the man page and supplement with google. Someone can pick a specific server(s) they want to use and test against. Yes there has to be something to all these different congestion control algo's. Geeks did not devote much time developing all these alternatives without reason surely.

Lately have been playing with BBR and dorking with Veno (a CCA = congestion control algo) which is supposed to be specifically designed for wireless(lossy) connections. Setting and changing these things is just a matter of adding a line to the /etc/sysctl.conf file, then comment it out or remove it, if someone wanted Cubic back. Here's my relevant lines from sysctl.conf.

## Here's where you choose congestion control algo. Veno is supposedly designed for lossy wireless connections.
#net.ipv4.tcp_congestion_control=veno
## This would enable the BBR congestion algo, # the above if you do.
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

In above I've got it so that I'm opting to use the BBR CCA. Imo for this, there flat out is no substitute for testing, like the speed test tool above, testing download speeds, webpg load speeds and other ways to track and monitor network throughput (how much data is going out/in.), how fast it's doing so in any this CCA vs another comparison test. Cubic is known to be a good general CCA, thus why it's still set default but there are one's specifically designed for xyz-usercase and newer supposedly better one's on the block = BBR.

Actually hoping some of us can get together on this and test. Bottomline though a better CCA means more data transferred faster on a persons network, thus faster web-browsing, quicker updates from software repo's etc etc. Someone won't know, unless they try some and confirm it's actually performing better with some degree of common sense and competent network testing. smile

Last edited by BLizgreat! (2019-11-14 10:21:25)

Offline

#12 2019-11-15 01:57:46

DeepDayze
Member
From: In Linux Land
Registered: 2017-05-28
Posts: 760

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

Wouldn't it be cool if you can automatically switch to Veno if you go from an Ethernet network connection to a wireless one?


Real Men Use Linux

Offline

#13 2019-11-15 05:08:40

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 1,180

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

Being gnu/Linux am about 210% certain there are more than a few ways to do it. If someone can dream it up, think of almost anything with their OS and computer, some geek already thought of it, developed a way to do it and it's sitting somewhere on the webz for anyone who looks to find. smile

Mean I can think of a couple possible approaches off the top, though are kind of hackish. Not really a nix-ninja, I just play one on the BL forums wink ie: Someone could have an alias, Veno="etc", BBR="same" etc, keycombo, menu item, panel launcher ... whatever, set to run a script which could toggle them and reload the things with "sudo sysctl -p" or similar. Another may be a crontab-etc set to run fairly often which could do likewise, monitoring which interface is connected and then automagically switch out CCA's. Am also sure systemd could do something with this too.

Atm exclusively stuck with wifi, plus a connection I've got limited control over so haven't bothered setting up anything for the ethernet interface and so haven't invested effort in the type of thing you're mentioning. Again ... though, don't doubt other nixers already have. Also fiddling without testing is no good. To really know, someone needs to test, test, test to see how a given CCA actually performs for their network, how they use their system. Haven't gotten around to it yet, ... it's on the 2-dork list though. No shortage of info on google. Like pretty much everything gnu/Nix, where there's a will, there's a way. smile

PS, general impression is that yes, Veno works better for my setup than Cubic did and BBR is neck and neck with Veno on wireless. Assume would clearly beat Veno and Cubic out on a wired connection. Won't truly know without testing though. Tuning the tcp stack and kernel tweaks with sysctl are a big topic unto themselves. I'm still splashing around in the kiddie pool mostly.

Last edited by BLizgreat! (2019-11-15 05:10:39)

Offline

#14 2019-11-16 03:11:58

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 1,180

Re: Changing the congestion control algo used in Bunsenlabs ( Debian. )

Oops, mis-post, wrong thread. tongue

Last edited by BLizgreat! (2019-11-16 03:14:48)

Offline

Board footer

Powered by FluxBB