Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's always TCP_NODELAY

brooker.co.za

Post reply on HN
Print view View original

141–150 of 276 posts

Re: It's always TCP_NODELAY

#141

Post by dataflow »

the8472 wrote: post #42
metadaemon wrote: post #37

Earlier quoted context omitted.

I'd just love a protocol that has a built in mechanism for realizing the other side of the pipe disconnected for any reason.

If a socket is closed properly there'll be a FIN and the other side can learn about it by polling the socket. If the network connection is lost due to external circumstances (say your modem crashes) then how would that information propagate from the point of failure to the remote end on an idle connection ? Either you actively probe (keepalives) and risk false positives or you wait until you hear again from the other…

> If the network connection is lost due to external circumstances (say your modem crashes) then how would that information propagate from the point of failure to the remote end on an idle connection?

Observe the line voltage? If it gets cut then you have a problem...

> Either you actively probe (keepalives) and risk false positives

What false positives? Are you thinking there's an adversary on the other side?

Re: It's always TCP_NODELAY

#144

Post by a_t48 »

nh2 wrote: post #134
ironman1478 wrote: post #56

I've fixed multiple latency issues due to nagle's multiple times in my career. It's the first thing I jump to. I feel like the logic behind it is sound, but it just doesn't work for some workloads. It should be something that an engineer needs to be forced to set while creating a socket, instead of letting the OS choose a default. I think that's the main issue. Not that it's a good / bad option but that there is a se…

Same here. I have a hobby that on any RPC framework I encounter, I file a Github issue "did you think of TCP_NODELAY or can this framework do only 20 calls per second?". So far, it's found a bug every single time. Some examples: https://cloud-haskell.atlassian.net/browse/DP-108 or https://github.com/agentm/curryer/issues/3 I disagree on the "not a good / bad option" though. It's a kernel-side heuristic for "magically…

Thanks for the reminder to set this on the new framework I’m working on. :)

Re: It's always TCP_NODELAY

#145

Post by eru »

bjourne wrote: post #122
temac wrote: post #8

Earlier quoted context omitted.

Fix the apps. Nobody expect magical perf if you do that when writing to files, even though the OS also has its own buffers. There is no reason to expect otherwise when writing to a socket and actually nagle already doesn't save you from syscall overhead.

> Fix the apps. Nobody expect magical perf if you do that when writing to files, We write to files line-by-line or even character-by-character and expect the library or OS to "magically" buffer it into fast file writes. Same with memory. We expect multiple small mallocs to be smartly coalesced by the platform.

Yes, your libraries should fix that. The OS (as in the kernel) should not try to do any abstraction.

Alas, kernels really like to offer abstractions.

Re: It's always TCP_NODELAY

#146

Post by eru »

syncsynchalt wrote: post #103
c0l0 wrote: post #10

Earlier quoted context omitted.

Especially for interactive sessions, it absolutely should! :)

Ironic since Nagle's Algorithm (which TCP_NODELAY disables) was invented for interactive sessions. It's hard to imagine interactive sessions making more than the tiniest of blips on a modern network.

Isn't video calling an interactive session?

Re: It's always TCP_NODELAY

#147

Post by eru »

rsc wrote: post #47

Not if you use a modern language that enables TCP_NODELAY by default, like Go. :-)

Why do you need a whole language for that? Couldn't you just use a 'modern' networking library?

Re: It's always TCP_NODELAY

#148

Post by projectileboy »

The real issue in modern data centers is TCP. Of course at present, we need to know about these little annoyances at the application layer, but what we really need is innovation in the data center at level 4. And yes I know that many people are looking into this and have been for years, but the economic motivation clearly has not yet been strong enough. But that may change if the public's appetite for LLM-based tooling causes data centers to increase 10x (which seems likely).

Re: It's always TCP_NODELAY

#149

Post by eru »

jedberg wrote: post #101

This is an interesting thing that points out why abstraction layers can be bad without proper message passing mechanisms. This could be fixed if there was a way for the application at L7 to tell the TCP stack at L4 "hey, I'm an interactive shell so I expect to have a lot of tiny packets, you should leave TCP_NODELAY on for these packets" so that it can be off by default but on for that application to reduce overhead.…

The take-away I get is that abstraction layers (in the kernel) can be bad.

Operating system kernels should enable secure multiplexing of resources. Abstraction and portability should be done via libraries.

See https://en.wikipedia.org/wiki/Exokernel

Re: It's always TCP_NODELAY

#150

Post by jandrese »

nh2 wrote: post #134
ironman1478 wrote: post #56

I've fixed multiple latency issues due to nagle's multiple times in my career. It's the first thing I jump to. I feel like the logic behind it is sound, but it just doesn't work for some workloads. It should be something that an engineer needs to be forced to set while creating a socket, instead of letting the OS choose a default. I think that's the main issue. Not that it's a good / bad option but that there is a se…

Same here. I have a hobby that on any RPC framework I encounter, I file a Github issue "did you think of TCP_NODELAY or can this framework do only 20 calls per second?". So far, it's found a bug every single time. Some examples: https://cloud-haskell.atlassian.net/browse/DP-108 or https://github.com/agentm/curryer/issues/3 I disagree on the "not a good / bad option" though. It's a kernel-side heuristic for "magically…

The problem with making it opt in is that the point of the protocol was to fix apps that, while they perform fine for the developer on his LAN, would be hell on internet routers. So the people who benefit are the ones who don't know what they are doing and only use the defaults.
Post reply on HN