6 ms·

The only reason this would be the case is if you are using network hubs or some ancient early 200's network equipmemt.

rcxdude 19d ago
And hubs like that wouldn't work with 1G anyway. (Apparently theoretically some versions of gigabit ethernet could work with hubs but it's not clear any were ever made)
adastra22 19d ago
Buffer exhaustion can cause it to happen pretty quickly with some normal, non-contrived usage patterns. A 10G host sending large data to a 100M peer will cause all packets between all other peers to drop once switch memory is filled up. Ideally the switch is smarter about this, but cheap switches in the real world…
- iso1631 19d ago
  You always get that no matter Imagine 5 devices that all push at 100mbit in 100 milliseconds (1gig linerate) to the target 1gig connected device, then nothing for 900ms. On paper they are feeding 100mbit a second each to a target receiving 500mbit a second. Easily fits in a 1gig link. But because of the timing you've got to transmit 500mbit in 100ms, or a peak speed of 5gbit. So instead you have to buffer and delay the packets. Your near-zero latency increases to 400ms, and your switch needs about 400mbit (50MB) of buffer, or over 30,000 packets of buffer space. You'd need a very high end switch to avoid any drops in that situation.
  - adastra22 18d ago
    I’m not an expert on switching algorithms, but there are various algos they can use for dropping or rejecting packets, or QoS prioritization that are supposed to self limit even a poorly implemented network protocol and provide fair service and reasonable latency even in such a situation. Again, a cheapo non reputable switch probably runs with whatever settings got it working the first time with no follow up testing. Networking algorithms are an area where the simple dumb thing mostly works except in edge cases and adversarial situations, and the right/proper way to do things is fiendishly complex.
    - justsomehnguy 18d ago
      If you claim > I’m not an expert on switching algorithms then you surely shouldn't tell about 'various algos' And no, no amount of software magik would help if your L1 can't handle the traffic.
- windexh8er 18d ago
  This is generally not related to the switch at all. It's upstream egress to the Internet and the most common cause is buffer bloat. Traffic on a 10Gb link between local hosts won't be impacted by a 100Mb connection going out to the Internet and also a 10Gb connection sending to a 100Mb connection won't either. TCP congestion control matches the speed of the sender and during an initial connection burst the switch will likely buffer for a short period of time (which is exactly why the buffer exists) and drains at line rate. This is normal and all during this TCP is signaling congestion / back off. However, if your egress router doesn't handle buffer bloat you can end up with poor connections leaving the network, but generally this isn't because of local Ethernet speed mismatch or related to the switch at all. And even in cheap switches (think Realtek / Broadcom chips in $30 switches) they have dynamic shared pools. An elephant flow can exhaust some of that pool, but even the cheap stuff won't allow a single port to exhaust all resources as claimed. 10Gb to 100Gb UDP? Sure... Maybe in this scenario you end up with some odd behavior, but this isn't going to be normal usage. We've got PAUSE frames, congestion control and hardware that's been doing this for decades. Even on the cheap switching. It is imperative to have a router, however that actually deals with buffer bloat appropriately and as your Internet pipe scales you want to be cognizant your router can handle queuing appropriately at those line rates. But ultimately... > A 10G host sending large data to a 100M peer will cause all packets between all other peers to drop once switch memory is filled up. ...is not true. Switches don't work like that.

And hubs like that wouldn't work with 1G anyway. (Apparently theoretically some versions of gigabit ethernet could work with hubs but it's not clear any were ever made)

adastra22 19d ago

Buffer exhaustion can cause it to happen pretty quickly with some normal, non-contrived usage patterns. A 10G host sending large data to a 100M peer will cause all packets between all other peers to drop once switch memory is filled up. Ideally the switch is smarter about this, but cheap switches in the real world…

iso1631 19d ago
You always get that no matter Imagine 5 devices that all push at 100mbit in 100 milliseconds (1gig linerate) to the target 1gig connected device, then nothing for 900ms. On paper they are feeding 100mbit a second each to a target receiving 500mbit a second. Easily fits in a 1gig link. But because of the timing you've got to transmit 500mbit in 100ms, or a peak speed of 5gbit. So instead you have to buffer and delay the packets. Your near-zero latency increases to 400ms, and your switch needs about 400mbit (50MB) of buffer, or over 30,000 packets of buffer space. You'd need a very high end switch to avoid any drops in that situation.
- adastra22 18d ago
  I’m not an expert on switching algorithms, but there are various algos they can use for dropping or rejecting packets, or QoS prioritization that are supposed to self limit even a poorly implemented network protocol and provide fair service and reasonable latency even in such a situation. Again, a cheapo non reputable switch probably runs with whatever settings got it working the first time with no follow up testing. Networking algorithms are an area where the simple dumb thing mostly works except in edge cases and adversarial situations, and the right/proper way to do things is fiendishly complex.
  - justsomehnguy 18d ago
    If you claim > I’m not an expert on switching algorithms then you surely shouldn't tell about 'various algos' And no, no amount of software magik would help if your L1 can't handle the traffic.
windexh8er 18d ago
This is generally not related to the switch at all. It's upstream egress to the Internet and the most common cause is buffer bloat. Traffic on a 10Gb link between local hosts won't be impacted by a 100Mb connection going out to the Internet and also a 10Gb connection sending to a 100Mb connection won't either. TCP congestion control matches the speed of the sender and during an initial connection burst the switch will likely buffer for a short period of time (which is exactly why the buffer exists) and drains at line rate. This is normal and all during this TCP is signaling congestion / back off. However, if your egress router doesn't handle buffer bloat you can end up with poor connections leaving the network, but generally this isn't because of local Ethernet speed mismatch or related to the switch at all. And even in cheap switches (think Realtek / Broadcom chips in $30 switches) they have dynamic shared pools. An elephant flow can exhaust some of that pool, but even the cheap stuff won't allow a single port to exhaust all resources as claimed. 10Gb to 100Gb UDP? Sure... Maybe in this scenario you end up with some odd behavior, but this isn't going to be normal usage. We've got PAUSE frames, congestion control and hardware that's been doing this for decades. Even on the cheap switching. It is imperative to have a router, however that actually deals with buffer bloat appropriately and as your Internet pipe scales you want to be cognizant your router can handle queuing appropriately at those line rates. But ultimately... > A 10G host sending large data to a 100M peer will cause all packets between all other peers to drop once switch memory is filled up. ...is not true. Switches don't work like that.