The Cargo Cult of TCP_nodelay: When to Use It | Hacker News Reader

The Cargo Cult of TCP_nodelay: When to Use It

withinboredom.info

40 pointswithinboredom17 comments

A well written article, however I felt it failed to address what appears to be an important factor, how berkely delayed acks interact badly with nagles tinygram prevention algorithm.

https://news.ycombinator.com/item?id=34180239

Delayed acknowledgements are mentioned, but as mentioned in the article, this is only a POTENTIAL issue if you can't fill packets and if BOTH sides are using Nagle's Algorithm (which shouldn't be the case, as mentioned in the article).

This is a follow-up from a story last week:

Golang is evil on shitty networks:

Golang disables Nagle's Algorithm by default

https://news.ycombinator.com/item?id=34179426 (805 points, 369 comments)

This, and most discussions about this seem to focus on situations where a human (browser) is on one side of the connection and the request flow is strait through.

In complex backed systems you have trees of requests to satisfy one browser request. Often the requests are small RPC type requests and even a few ms is important.

For me, no delay is 10% to 30% faster on every permutation of the benchmark, on WiFi, 4g and 5g.

You must have a really nice network all the way to my servers.

I just tried it with and without private relay, with the same results.

I’m connecting from London via an iPhone, where are your servers?

And out of interest, do you log the results of the benchmark anywhere? Would be cool to capture it.

Finland. I wouldn’t be surprised if you are only a few hops away. I have 16 hops in the Netherlands

No, I’m not storing the results. I guess there are technically access logs but that doesn’t tell me anything.

Maybe you should? It would be interesting to see if the results line up with your expectations.

It could be the case where buffer management on routers along the way makes a difference, transient congestion conditions, buffer sizes, fq vs fifo vs something more complicated, etc.

Things work a lot faster if all of your small packets make it through, but if any of those packets are dropped you incur delays for retransmits, tcp slow start, etc. Basically extra round-trip delays that could be a lot longer than a local nagle delay, depending on what you are sending.

It's amazing how many learned lessons we have to relearn. Should we learn why Nagle's algorithm exists and how best to exploit it? Nah, just disable it.

Should we learn why it exists and how to exploit it? Absolutely. At the same time Nagle himself showed up in the comments about the previous article saying disabled by default (what Go was doing) is probably the better approach these days so I don’t think it’s accurate or helpful to claim calls for it are just a result of people that don’t understand it.

The thing it was trying to solve (and does solve) is specifically when there is congestion (lots of packet drops beyond slow-start). If you have those network conditions, AND you aren't filling packets ... then Nagle's Algorithm is for you. That was the entire point of the article.

You really should not rely on OS and make small `send()` syscalls in hope it would magically work. Too much overhead.

This is not how to best interact with Nagle's algorithm.

But it's original intention was to fix this very issue.

Reply on news.ycombinator.com