Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Another update, not majorly significant but one I'll share anyway.

I had a letter through the letterbox yesterday, virtually identical to the one I had before (which I'm now starting to wonder if I should've had in the first place). However, the major difference this time is that they've been previously working on the other half of the longish road I'm on. Now there's roadworks planned by Lightning Fibre virtually at the telegraph pole I'm connected to. I believe I possibly received the first letter in error due to longish the road and the funny route it takes. Once again the letter says I should be able to connect to Lightning Fibre within a month from now (or something to that effect), which would co-incide with the planned roadworks here and a few weeks leeway after the planned finish date.

Exciting times ahead perhaps, maybe I'll be able to signup and go live before Christmas .

I've not had a follow up regarding the request for multiple IP addresses, but I suspect that might not be possible at this time. When I look at how many they appear to have on their ASN, which I assume includes allocations for customer connections, it's unlikely to be adequate for those who would need or want multiple IP addresses at the moment (512 + 512 + 32,768 + 2,048).

P.S. I can't update the thread's original title, so if a moderator can remove the 'updated xx/xx/xxxx' bit that'll be fine. Thanks.

baby

meaning clarified

stirrups

scattered across the

quadrophonic sound systems designer

@chrys and likewise ditto for IPv6 too in Linux ?

I've not seen

Code: [Select]

net.ipv4.tcp_notsent_lowat=16384 mentioned before.  Its certainly a curious one given the default on Fedora is

Code: [Select]

net.ipv4.tcp_notsent_lowat = 4294967295 so just slightly different.

I see it seems to be related to making http/2 work best https://blog.cloudflare.com/http-2-prioritization-with-nginx/ and it specifically mentions servers rather than clients.  So not sure its necessary on the client side, though it does seem like it would reduce bufferbloat.

The command to switch should be as simple as

'sysctl net.ipv4.tcp_congestion_control=bbr'
also recommended 'sysctl net.core.default_qdisc=fq' and 'net.ipv4.tcp_notsent_lowat=16384'

To keep them on reboot.

'echo >> net.ipv4.tcp_congestion_control=bbr /etc/sysctl.conf'
'echo >> net.core.default_qdisc=fq /etc/sysctl.conf'
'echo >> net.ipv4.tcp_notsent_lowat=16384 /etc/sysctl.conf'

Looking at the available configuration options, for TCP congestion control in the latest linux-5.15-rc6 sources, I have --

[config-5.15-rc6]$ grep 'CONFIG_TCP_CONG_' *
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=m
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_NV=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_TCP_CONG_DCTCP=m
CONFIG_TCP_CONG_CDG=m
CONFIG_TCP_CONG_BBR=m
[config-5.15-rc6]$

Right at the bottom we see the "newest" addition, BBR.

Every option is built as a module and its up to the userland process(es) to make use of one of them, as appropriate.