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

171–180 of 186 posts

Re: It's Always TCP_NODELAY

#171

Post by yxhuvud »

mort96 wrote: post #88
FridgeSeal wrote: post #76

Earlier quoted context omitted.

If nobody is maintaining them, do we really need them? In which case, does it really matter? If we need them, and they’re not being maintained, then maybe that’s the kind of “scream test” wake up we need for them to either be properly deprecated, or updated.

How much ongoing development effort do you think goes into, say, something like a gzip encoder?

A gzip encoder has no business deciding whether a socket should wait to fill up packets, however. The list of relevant applications and libraries gets a lot shorter with that restriction.

Re: It's Always TCP_NODELAY

#172

Post by cyberax »

drewg123 wrote: post #153
paulsutter wrote: post #151

Earlier quoted context omitted.

TCP Reno Vegas etc all addressed congestion control with various ideas, but were all doomed by the academic downward spiral pissing contest. QUIC is real and works great, and they sidestepped all of that and just built it and tuned it and has basically won. As for QUIC "sending more parts of the page in parallel" yes thats what I referred to re head of line blocking in TCP.

There is nothing magic about the congestion control in QUIC. It shares a lot with TCP BBR. Unlike TLS over TCP, QUIC is still not able to be offloaded to NICs. And most stacks are in userspace. So it is horrifically expensive in terms of watts/byte or cycles/byte sent for a CDN workload (something like 8x as a expensive the last time I looked), and its primarily used and advocated for by people who have metrics for l…

> Unlike TLS over TCP, QUIC is still not able to be offloaded to NICs.

That's not quite true. You can offload QUIC connection steering just fine, as long as your NICs can do hardware encryption. It's actually _easier_ because you can never get a QUIC datagram split across multiple physical packets (barring the IP-level fragmentation).

The only real difference from TCP is the encryption for ACKs.

Re: It's Always TCP_NODELAY

#173

Post by anonymousiam »

reorder9695 wrote: post #152
anonymousiam wrote: post #150

Earlier quoted context omitted.

But CSMA/CD also has a backoff period.

CSMA/CD only requires that you back off if there actually is a collision. CSMA/CA additionally requires that for every frame sent, after sensing the medium as clear, that you wait for a random amount of time before sending it to avoid collisions. If the medium is frequently clear, CA will still have the overhead of this initial wait where CD will not.

Depending upon how it's actually implemented, CSMA/CA may have the same (untended?) behavior of CSMA/CD in the sense that setting TCP_NODELAY will also set the backoff timer to zero. It would be interesting to test.

(My other post in this thread mentions it.) https://news.ycombinator.com/item?id=46360209#46361580

Re: It's Always TCP_NODELAY

#175

Post by mort96 »

yxhuvud wrote: post #171
mort96 wrote: post #88

Earlier quoted context omitted.

How much ongoing development effort do you think goes into, say, something like a gzip encoder?

A gzip encoder has no business deciding whether a socket should wait to fill up packets, however. The list of relevant applications and libraries gets a lot shorter with that restriction.

It was a response to the sentiment expressed in:

> If nobody is maintaining them, do we really need them?

Software can have value even when not maintained.

Re: It's Always TCP_NODELAY

#176

Post by mort96 »

immibis wrote: post #114
silisili wrote: post #32

Earlier quoted context omitted.

At this point, this is an application level problem and not something the kernel should be silently doing for you IMO. An option for legacy systems or known problematic hosts fine, but off by default and probably not a per SOCKOPT. Every modern language has buffers in their stdlib. Anyone writing character at a time to the wire lazily or unintentionally should fix their application.

So to be clear, you believe every program that outputs a bulk stream to stdout should be written to check if stdout is a socket and enable Nagle's algorithm if so? That's not just busywork - it's also an abstraction violation. By explicitly turning off Nagle's, you specify that you understand TCP performance and don't need the abstraction, and this is a reasonable way to do things. Imagine if the kernel pinned thread…

> That's not just busywork - it's also an abstraction violation.

You used AI to write this didn't you? Your sentence structure is not just tedious - it's a dead give-away.

Re: It's Always TCP_NODELAY

#177

Post by drewg123 »

cyberax wrote: post #172
drewg123 wrote: post #153

Earlier quoted context omitted.

There is nothing magic about the congestion control in QUIC. It shares a lot with TCP BBR. Unlike TLS over TCP, QUIC is still not able to be offloaded to NICs. And most stacks are in userspace. So it is horrifically expensive in terms of watts/byte or cycles/byte sent for a CDN workload (something like 8x as a expensive the last time I looked), and its primarily used and advocated for by people who have metrics for l…

> Unlike TLS over TCP, QUIC is still not able to be offloaded to NICs. That's not quite true. You can offload QUIC connection steering just fine, as long as your NICs can do hardware encryption. It's actually _easier_ because you can never get a QUIC datagram split across multiple physical packets (barring the IP-level fragmentation). The only real difference from TCP is the encryption for ACKs.

From a CDN perspective, whats missing is there is no kernel stack on FreeBSD / Linux, and no support for sendfile/sendpage and no support for segmentation offload entirely in hardware. So you can't just send an entire file (or a large range) and forget about it, like you can with TCP.

Some NICs, like Broadcom's newer ones, support crypto offloads, but this is not enough to be competitive with TCP / TLS. Especially since support for those offloads are not in any mainline kernel in Linux or BSD.

Re: It's Always TCP_NODELAY

#178

Post by littlecranky67 »

CamperBob2 wrote: post #156
littlecranky67 wrote: post #78

Earlier quoted context omitted.

It delays one RTT, so if you have seen seconds of delays that means your TCP ACK packages were received seconds later for whatever reason (high load?). Decreasing latency in that situation would WORSEN the situation.

Maybe, maybe not, whatever. I was testing some low-bandwidth voice chat code using two unloaded PCs sitting on the same desk. I nearly jumped out of my skin when "HELLO, HELLO?" came through a few seconds late, at high volume, after I had already concluded it wasn't working. After ruling out latency on the audio side, TCP_NODELAY solved the problem. All respect to Animats, but whoever thought this should be the defau…

Whatever your issue in that setup was, NODELAY had nothing to do with it

Re: It's Always TCP_NODELAY

#179

Post by derriz »

mkipper wrote: post #159
derriz wrote: post #132

Earlier quoted context omitted.

I don’t understand your point here or maybe our understanding of the admittedly vague term “message oriented” differs. I’m not suggesting exposing retransmission, fragmentation, etc to the API user. The sender provides n bytes of data (a message) to the network stack. The receiver API provides the user with the block of n bytes (the message) as part of an atomic operation. Optionally the sender can be provided with n…

I think you're misunderstanding their point. Your API is constrained by the actual TCP protocol. Even if the sender uses this message-oriented TCP API, the receiver can't make any guarantees that a packet they receive lines up with a message boundary, contains N messages, etc etc, due to how TCP actually works in the event of dropped packets and retransmissions. The receiver literally doesn't have the information nee…

Fair enough - I didn’t really fully consider the effect of retransmission and segmentation on the receiver view.

Re: It's Always TCP_NODELAY

#180

Post by immibis »

mort96 wrote: post #176
immibis wrote: post #114

Earlier quoted context omitted.

So to be clear, you believe every program that outputs a bulk stream to stdout should be written to check if stdout is a socket and enable Nagle's algorithm if so? That's not just busywork - it's also an abstraction violation. By explicitly turning off Nagle's, you specify that you understand TCP performance and don't need the abstraction, and this is a reasonable way to do things. Imagine if the kernel pinned thread…

> That's not just busywork - it's also an abstraction violation. You used AI to write this didn't you? Your sentence structure is not just tedious - it's a dead give-away.

No, I did not. Am I now forbidden from using sentence structures that AI has also used? That's not just stupid - it's insane. You know that's not even an em-dash, right?
Post reply on HN