Uhh.. I work with this stuff daily and there are a LOT of intrinsic reasons a single stream would be slower than running multiple: MPLS ECMP hashing you over a single path, a single loss event with a high BDP causing congestion control to kick in for a single flow, CPU IRQ affinity, probably many more I’m not thinking like the inner workings of NIC offloading queues.

Source: Been in big tech for roughly ten years now trying to get servers to move packets faster

▲

digiown 7 hours ago | parent [-]

Ha, it sounds like the best way to learn something is to make a confident and incorrect claim :)

> MPLS ECMP hashing you over a single path

This is kinda like the traffic shaping I was talking about though, but fair enough. It's not an inherent limitation of a single stream, just a consequence of how your network is designed.

> a single loss event with a high BDP

I thought BBR mitigates this. Even if it doesn't, I'd still count that as a TCP stack issue.

At a large enough scale I'd say you are correct that multiple streams is inherently easier to optimize throughput for. But probably not a single 1-10gb link though.

	▲	PunchyHamster 3 hours ago \| parent [-]
		> This is kinda like the traffic shaping I was talking about though, but fair enough. It's not an inherent limitation of a single stream, just a consequence of how your network is designed. It is. one stream gets you traffic of one path to the infrastructure. Multiple streams get you multiple and possibly also hit different servers to accelerate it even more. Just the limitation isn't hardware but "our networking device have 4 10Gbit ports instead of single 40Gbit port" Especially if link is saturated, you'd be essentially taking n-times your "fair share" of bandwidth on link.