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

91–100 of 186 posts

Re: It's Always TCP_NODELAY

#91

Post by mort96 »

wyldfire wrote: post #71

Nagle's algorithm is just a special case of TCP worst case latency. Packet loss and congestion also cause significant latency. If you care about latency, you should consider something datagram oriented like UDP or SCTP.

What if occasional latency is fine, and latency on terrible networks with high packet loss is fine, but you want the happy case to have little latency? Both many (non-competitive) games and SSH falls into this: reliability is more important than achieving the absolute lowest latency possible, but lower latency is still better than higher latency.

Re: It's Always TCP_NODELAY

#92

Post by Hikikomori »

mikestorrent wrote: post #64
Hikikomori wrote: post #23

Earlier quoted context omitted.

Just to add, ethernet uses csma/cd, WiFi uses csma/ca. Upgraded our DC switches to new ones around 2014 and needed to keep a few old ones because the new ones didn't support 10Mbit half duplex.

What did you still need to connect with 10mbit half duplex in 2014? I had gigabit to the desktop for a relatively small company in 2007, by 2014 10mb was pretty dead unless you had something Really Interesting connected....

Some old DEC devices used to connect console ports of servers. Didn't need it per say but also didn't need to spend $3k on multiple new console routers.

Was an old isp/mobile carrier so could find all kinds of old stuff. Even the first SMSC from the 80s (also DEC, 386 or similar cpu?) was still in it's racks because they didn't need the rack space as 2 modern racks used up all the power for that room, was also far down in a mountain so was annoying to remove equipment.

Re: It's Always TCP_NODELAY

#93

Post by josefx »

x2rj wrote: post #20

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…

I think you could try to add the flat MSG_MORE to every send command and then do a last send without it to indirectly do a flush.

Re: It's Always TCP_NODELAY

#94

Post by hinkley »

silisili wrote: post #32
immibis wrote: post #24

Earlier quoted context omitted.

Nagle is quite sensible when your application isn't taking any care to create sensibly-sized packets, and isn't so sensitive to latency. It avoids creating stupidly small packets unless your network is fast enough to handle them.

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.

I think you’re forgetting how terminals work.

Re: It's Always TCP_NODELAY

#96

Post by mgaunard »

rwmj wrote: post #79

I'm surprised the article didn't also mention MSG_MORE. On Linux it hints to the kernel that "more is to follow" (when sending data on a socket) so it shouldn't send it just yet. Maybe you need to send a header followed by some data. You could copy them into one buffer and use a single sendmsg call, but it's easier to send the header with MSG_MORE and the data in separate calls. (io_uring is another method that helps…

you can already send fragmented data in one system call without copying it to a single buffer.

Re: It's Always TCP_NODELAY

#97

Post by mgaunard »

mort96 wrote: post #90
calineczka wrote: post #63

Earlier quoted context omitted.

> message oriented Very well said. I think there is enormous complexity in many layers because we don't have that building block easily available.

It's the main reason why I use websockets for a whole lot of things. I don't wanna build my own message chunking layer on top of TCP every time.

WebSocket is full of web-tech silliness; you'd be better off doing your own framing.

Re: It's Always TCP_NODELAY

#98

Post by TZubiri »

> , suggesting that the default behavior is wrong, and perhaps that the whole concept is outmoded

While outmoded might be the case, wrong is probably not the case.

There's some features of the network protocols that are designed to improve the network, not the individual connection. It's not novel that you can improve your connection. By disabling "good neighbour" features.

Re: It's Always TCP_NODELAY

#99

Post by mgaunard »

derriz wrote: post #47
x2rj wrote: post #20

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…

Yeah, I’ve always felt that the stream API is a leaky abstraction for providing access to networking. I understand the attraction of making network I/O look like local file access given the philosophy of UNIX. The API should have been message oriented from the start. This would avoid having the network stack try to compensate for the behavior of the application layer. Then Nagel’s or something like it would just be a…

the whole point of TCP is that it is a stream of bytes, not of messages.

The problem is that this is not in practice quite what most applications need, but the Internet evolved towards UDP and TCP only.

So you can have message-based if you want, but then you have to do sequencing, gap filling or flow control yourself, or you can have the overkill reliable byte stream with limited control or visibility at the application level.

Re: It's Always TCP_NODELAY

#100

Post by TZubiri »

miduil wrote: post #6
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…

There is also a good write-up [0] by Julia Evans. We ran into this with DICOM storescp, which is a chatty protocol and TCP_NODELAY=1 makes the throughput significantly better. Since DICOM is often used in a LAN, that default just makes it unnecessarily worse. [0]: https://jvns.ca/blog/2015/11/21/why-you-should-understand-a-... [1]: https://news.ycombinator.com/item?id=10607422

I wonder how this fix could be implemented without source code access. Suppose an old ct scanner is clogging up the network.
Post reply on HN