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

11–20 of 186 posts

Re: It's Always TCP_NODELAY

#11

Post by kvemkon »

martingxx wrote: post #5

I've always thought that Nagle's algorithm is putting policy in the kernel where it doesn't really belong. If userspace applications want to make latency/throughput tradeoffs they can already do that with full awareness and control using their own buffers, which will also often mean fewer syscalls too.

The tradeoff on one program can influence the other program needing perhaps the opposite decision of such tradeoff. Thus we need the arbiter in the kernel to be able to control what is more important for the whole system. So my guess.

Re: It's Always TCP_NODELAY

#12

Post by saghm »

I first ran into this years ago after working on a database client library as an intern. Having not heard of this option beforehand, I didn't think to enable it in the connections the library opened, and in practice that often led to messages in the wire protocol being entirely ready for sending without actually getting sent immediately. I only found out about it later when someone using it investigated why the latency was much higher than they expected, and I guess either they had run into this before or were able to figure out that it might be the culprit, and it turned out that pretty much all of the existing clients in other languages set NODELAY unconditionally.

Re: It's Always TCP_NODELAY

#14

Post by ghshephard »

martingxx wrote: post #5

I've always thought that Nagle's algorithm is putting policy in the kernel where it doesn't really belong. If userspace applications want to make latency/throughput tradeoffs they can already do that with full awareness and control using their own buffers, which will also often mean fewer syscalls too.

It's kind of in User Space though - right? When an application opens a socket - it decides whether to open it with TCP_NODELAY or not. There isn't any kernel/os setting - it's done on a socket by socket basis, no?

Re: It's Always TCP_NODELAY

#17

Post by naught00 »

ghshephard wrote: post #14
martingxx wrote: post #5

I've always thought that Nagle's algorithm is putting policy in the kernel where it doesn't really belong. If userspace applications want to make latency/throughput tradeoffs they can already do that with full awareness and control using their own buffers, which will also often mean fewer syscalls too.

It's kind of in User Space though - right? When an application opens a socket - it decides whether to open it with TCP_NODELAY or not. There isn't any kernel/os setting - it's done on a socket by socket basis, no?

TCP_NODELAY is implemented within the kernel. A socket can decide whether to use it or not.

Re: It's Always TCP_NODELAY

#18

Post by sail0rm00n »

eieio wrote: post #2

I found this article while debugging some networking delays for a game that I'm working on. It turns out that in my case it wasn't TCP_NODELAY - my backend is written in go, and go sets TCP_NODELAY by default! But I still found the article - and in particular Nagle's acknowledgement of the issues! - to be interesting. There's a discussion from two years ago here: https://news.ycombinator.com/item?id=40310896 - but I…

Any details on the game you’ve been working on? I’ve been really enjoying Ebitengine and Golang for game dev so would love to read about what you’ve been up to!

Re: It's Always TCP_NODELAY

#19

Post by klempner »

martingxx wrote: post #5

I've always thought that Nagle's algorithm is putting policy in the kernel where it doesn't really belong. If userspace applications want to make latency/throughput tradeoffs they can already do that with full awareness and control using their own buffers, which will also often mean fewer syscalls too.

The actual algorithm (which is pretty sensible in the absence of delayed ack) is fundamentally a feature of the TCP stack, which in most cases lives in the kernel. To implement the direct equivalent in userspace against the sockets API would require an API to find out about unacked data and would be clumsy at best.

With that said, I'm pretty sure it is a feature of the TCP stack only because the TCP stack is the layer they were trying to solve this problem at, and it isn't clear at all that "unacked data" is particularly better than a timer -- and of course if you actually do want to implement application layer Nagle directly, delayed acks mean that application level acking is a lot less likely to require an extra packet.

Re: It's Always TCP_NODELAY

#20

Post by x2rj »

I've always thought a problem with Nagel's algorithm is, that the socket API does not (really) have a function to flush the buffers and send everything out instantly, so you can use that after messages that require a timely answer.

For stuff where no answer is required, Nagel's algorithm works very well for me, but many TCP channels are mixed use these days. They send messages that expect a fast answer and other that are more asynchronous (from a users point of view, not a programmers).

Wouldn't it be nice if all operating systems, (home-)routers, firewalls and programming languages would have high quality implementations of something like SCTP...

Post reply on HN