[blibble]

> Correct they can't. Managed switches without qos set up can't prioritise traffic either.

> If your switch is dropping packets, you don't have enough bandwidth.

this isn't true, there exist more bottlenecks than just bandwidth, e.g. try sending 10 byte packets instead of 1500 byte packets and watch as your switch starts dropping due to CPU exhaustion

> Ultimately it comes down to how big your buffers are whether your packet gets through or not

not really, traffic prioritisation is about deciding which packets you drop when hitting your limits (or close to), not making sure that you never drop anything

obviously if you're never hitting any bottlenecks: the prioritisation does nothing

[iso1631]

Dunno how you'd make a 10 byte packet, the smallest valid ethernet packet was 64 bytes, and I'd expect my switch to forward those at line speed just fine, and drop any runt packets just fine too. Maybe you could hack a network driver to deliver some really nasty frames, but that doesn't seem a likely situation for rsyncs use case -- not compared with a switch failure for other means.

The point about QOS is that it often isn't necessary because you shouldn't be hitting those limits, and if you do you often don't care (because you've got half a dozen identical desktop computers talking to an unmanaged network not doing any relevant dscp marking). In rsyncs case the traffic they're sending is all ssh traffic - what's going to be doing the tagging and differentiation?

[mcosta]

> not really, traffic prioritisation is about deciding which packets you drop when hitting your limits

But everything is the same: ssh traffic for backups. And both ends do congestion control.

I don't care if nightly backups take 1 or 2 hours.