Hacker News Reader

Comment by eieio | Hacker News Reader

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 figured it'd been long enough that others might be interested in giving this a read too.

View on HN

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

Oh! Thank you for this! I love Julia’s writing but haven’t read this post.

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

https://github.com/sschroe/libnodelay

Oh, DICOM really like to talk back and forth... I guess that nowadays it should be better with all the WEB/REST versions of the protocol.

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!

I've been playing with multiplayer games that run over SSH; right now I'm trying to push the framerate on the games as high as I can, which is what got me thinking about my networking stack.

I mostly use go these days for the backend for my multiplayer games, and in this case there's also some good tooling for terminal rendering and SSH stuff in go, so it's a nice choice.

(my games are often pretty weird, I understand that "high framerate multiplayer game over SSH" is a not a uhhh good idea, that's the point!)

Two things that can have a big impact on SSH throughput are cipher choice and the hardcoded receive buffer size. These are described in the fork https://github.com/rapier1/hpn-ssh

Maybe that will be useful for thinking about workarounds or maybe you can just use hpn-ssh.

ah this is great, thanks dan!

Reply on news.ycombinator.com