2 ms·
> 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 bandwidt
by blibble 6y ago
> 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 6y agoDunno 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 6y ago> 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.