I don’t know how expensive it is to pin down something but it should scale up quite nicely and does not require any synchronization by itself.

Bests Lars

This was done, though it wasn’t mentioned. All roaming was disabled. There’s local radar and lots of reflections around me, so most likely it was interference.

It turns out there are random 50-100ms delays all over the place. Probably due to interference.

No, it’s probably periodic background scanning of other networks. Try to “lock” your connection to your network mac address only to prevent that.

The idea isn’t to have it on for the entire request but turn it off when doing bulk transfers if and only if you aren’t filling packets (lots of small writes). If you’re filling packets, it doesn’t matter unless there is congestion after slow-start.

Nagle’s algorithm by itself is a pure evil. I’ve never seen any production highload system that didn’t set TCP_NODELAY on its sockets. That is why Golang did it by default. It is good decision.

But that means one should always buffer its io. It is always good thing to buffer it in userspace. Nagle’s algorithm were born for those program’s that for some reason couldn’t do it. That it because telnet/ssh were single threaded, and they didn’t have a way to “wait for user input for some more and flush buffer after N ms either there was user input or not”. (Well, they could use SIGALARM, but for some reason they didn’t). Instead Nagle’s algorithm were introduced to work around their shortcomings, and by misfortune it were made as the default for all sockets.

each of those 50 bytes are sent out as one packet instead of just a few bigger packets

This wording is confusing, since “one packet” is surely fewer than “a few packets”. It should probably say “sent out as individual packets”.