101–110 of 117 posts
This doc kinda needs to say "TCP" somewhere, as it's very focused on TCP concerns - which is useful, people are mostly using TCP. The default UDP tunings are awfully low and as such are notably missing.
Do you have any good resources for UDP tuning?
net.core.rmem_max net.core.wmem_max
e.g. wireguard-go will hit those limits of not executed with CAP_NET_ADMIN.
Earlier quoted context omitted.
There are 3 revisions of i225 and Intel essentially got rid of it and launched i226. That one also seems to be problematic [1] . Why is it exponentially harder to make a 2.5gbps NIC when the 1gbps NIC (i210 and i211) has worked well for them. Shouldn't it be trivial to make it 2.5x? They seem to make good 10gbps NICs so I would assume 2.5gbps shouldn't need a 5th try from intel ? [1] - https://shorturl.at/esCNP
I'm interested in clicking your link just not through a shortener. Perhaps just my own bias but figured I'd surface that reaction here. Much more useful to see the domain I'll end up on.
Earlier quoted context omitted.
net.ipv4.tcp_rmem max is a limit for the auto-tuning the kernel performs once you do SO_RCVBUF the auto-tuning is out of the picture for that socket, and net.core.rmem_max becomes the max. It's pretty clearly documented @ Documentation/networking/ip-sysctl.rst Edit: downvotes, really? smh
And to add: the kernel autotunes better than you can, so leave that enabled unless you're Vint Cert, Jim Gettys, or Vern Paxton.
But can anybody help me out, who tunes linux network parameters on a regular basis?
Brendan's System Performance books provide nice coverage on Linux network performance and more [1]. It's already in the second edition, both are excellent books but the 2nd edition focuses mainly on Linux whereas the 1st edition also include Solaris.
There's also a more recent book on BPF Performance Tools by him [2].
[1] Systems Performance: Enterprise and the Cloud, 2nd Edition (2020)
https://www.brendangregg.com/systems-performance-2nd-edition...
[2] BPF Performance Tools:
https://www.brendangregg.com/bpf-performance-tools-book.html
Earlier quoted context omitted.
The original cargo cultists built runways on islands to cause supplies to be dropped off. It didn't work. If someone copy and pasted something they don't fully understand off the Internet, but it works , can you really blame them for it, or call them cargo cultists?
Except it doesn't work. It's easy to coax BBR into converging on using 20% of a shared link instead of 50% (cohabiting with one other stream). The inverse is true and it's easy to get BBR to hog 80% of a link instead of 50% (cohabiting with one other stream). If you're happy for other people to steal bandwidth from you with greedy CCAs then go ahead and ratelimit yourself. I'm not.
E.g. if a service runs on a single server (no CDN) and you occasionally get users from Australia then the site will by a bit laggy for them but at least it won't be a trickle.
This doc kinda needs to say "TCP" somewhere, as it's very focused on TCP concerns - which is useful, people are mostly using TCP. The default UDP tunings are awfully low and as such are notably missing.
Do you have any good resources for UDP tuning?
It's older so some details have changed over time, but the concepts are still relevant. It also has a lot of useful search terms to get you started.
Could anyone recommend a video or video series covering similar material? There lots on networking in general, but I've had a hard time finding some on Linux specific implementation
I'm also seconding this, but from microcontroller perspective. I want to try developing a simple tcp echo server for a microcontroller, but most examples just use the vendor's own tcp library and put no effort explaining how to manually setup and establish connection to the router.
Just changing Linux's default congestion control (net.ipv4.tcp_congestion_control) to 'bbr' can make a _huge_ difference in some scenarios, I guess over distances with sporadic packet loss and jitter, and encapsulation. Over the last year, I was troubleshooting issues with the following connection flow: client host reverse proxy host service host On average, I could not get better than 20% theoretical max throughput.…
The difference is that BBR does not use loss as a signal of congestion. Most TCP stacks will cut their send windows in half (or otherwise greatly reduce them) at the first sign of loss. So if you're on a lossy VPN, or sending a huge burst at 1Gb/s on a 10Mb/s VPN uplink, TCP will normally see loss, and back way off. BBR tries to find Bottleneck Bandwidth rate. Eg, the bandwidth of the narrowest or most congested link…
Earlier quoted context omitted.
The difference is that BBR does not use loss as a signal of congestion. Most TCP stacks will cut their send windows in half (or otherwise greatly reduce them) at the first sign of loss. So if you're on a lossy VPN, or sending a huge burst at 1Gb/s on a 10Mb/s VPN uplink, TCP will normally see loss, and back way off. BBR tries to find Bottleneck Bandwidth rate. Eg, the bandwidth of the narrowest or most congested link…
> Most TCP stacks will cut their send windows in half (or otherwise greatly reduce them) at the first sign of loss. This was obsoleted by fast retransmit which was standardized in the 90s and ~everyone uses, right? (loss generally is still used as a congestion signal, but first loss is usually not)