[klabb3]

60ms @ 1gbit (120 MiB) -> 7.2 MiB TCP buffer size required for bandwidth saturation. That’s more than the max buffer size a run-of-the-mill modern OS gives you by default, meaning your download speeds will be capped unless you fiddle with sysctl or equivalent. And that’s within the same continent assuming minimal jitter and packet loss.

Another big one is optimizing applications for number of round trips, which most people don’t do, and it can be surprisingly hard to do so.

I am a throughput freak, but you’d be surprised at the importance of latency, even (especially?) for throughput, in practice. It’s absolutely not just a “real-time” thing.

If you’re on Linux, you can use ‘netem’ to emulate packet loss, latency etc. Chrome dev tools have something similar too, it’s an eye opening experience if you’re used to fast reliable internet.

[zamadatix]

> 60ms @ 1gbit (120 MiB) -> 7.2 MiB TCP buffer size required for bandwidth saturation. That’s more than the max buffer size a run-of-the-mill modern OS gives you by default

Windows was quite happy to give me a 40,960 * 512 = 20,971,520 byte TCP window for a single stream speed test from mid US to London, run via Chrome. Linux is the only one I've noticed with stingy max buffers. I never really understood why user-focused distros like to keep the max so limited when there are plenty of resources.

[klabb3]

That’s great to hear! Thanks for the data point, hope this is more representative. I’ve encountered Windows (10) instances in the wild with auto-tuning turned off (64k max).

> I never really understood why user-focused distros like to keep the max so limited when there are plenty of resources.

Yeah, agreed. That is way too conservative, especially for an issue which most people can’t easily triage.

[zamadatix]

You can definitely turn it off in Windows, should you want to for some reason, but scaling windows up to 1G are definitely the default since Windows 2000 https://web.archive.org/web/20130613080612/http://www.micros...