LAN adapter selection 10M -vs- 100Mbit/s

Johnny wrote in news: snipped-for-privacy@4ax.com:

Not moderately. But if things get worse and a switch is in the mix the

You could start here, it's pretty simple.

You're welcome in arears.

Not if the switch doing the networking is worth its salt.

If you don't actually need more than 10 Mbit/s, using 100 Mbit/s hardware is likely to be a waste of both money and energy.

Hans-Bernhard Broeker wrote in news: snipped-for-privacy@uni-berlin.de:

How so? If packets destined for the 10Mbit/s device are incoming to the switch on a Gbe link and the packet memory in the switch fills up, how does any switch become worth its salt and continue to route packets to the remaining 100Mbit/s ports? No, pause frames are not allowed.

No. Only an obsolete part would be that much less expensive, IMHO ;-)

That IS a question worth asking: if the network is composed of HUBS (not switches) then all NIC see any transaction (and must to respect contention). Therefore a packet for the 10Mb unit would take 10x the bandwidth of the same packet for the other. For one embedded gadget at low usage, no sweat. But if someone makes up a test lab for testing 1000 units at a shot it could be an issue!

Generally, no.

Does it help to say it is handled by the NIC and the NIC driver? - RM

Then the OP's condition that a 10Mbit/s link is all the device needs must have been violated.

Yes, those extra 990 Mbit/s of data *must* be dropped at some point, and it's neither the 10Mbit/s device nor the switch that bears the responsibility for that problem --- it's the data source at the other end of the Gbit link.

Have you found products on the market that actually work this way? I can't imagine they'd last long.

The approach on well-designed switches is to limit the output queue depth on each port. When that queue fills up, that port experiences packet loss. Other ports are unaffected.

Not really. Because there is no such thing as a HUB that you can connect both 10Mb and 100Mb devices to, simultaneously. There some devices that claim to be such "dual-speed Hubs", but in reality, those are (simple) switches.

Such a "someone" would deserve whatever problems they got.

Check out the ASIX AX88796L. It's a 10/100 NE2000-based ISA controller. IIRC, the cost difference in reasonable quantity was not much higher than a Realtek 10Mb chip.

It'll make no difference to other devices on the network. In most cases, it'll make no difference to your device either.

Where it can matter is if your device sees a relatively high volume of data from the network (or even moderate levels, if you're trying to transmit a lot of data). This can happen for a variety of reasons, even in a switched network, but generally shouldn't be an issue if you're sending a low volume of data (say, Can anyone explain how 10 / 100 auto-dectection works?

There's an encoding in the link signalling, IIRC. It's a level of detail that isn't typically documented in the chip specs because "it just happens" when you enable it on the controller. If you really want to understand the encoding, you can download the related 802.3 specs from IEEE for free, but it's likely to be a beastly set of docs.

As the chokepoint, the switch has a hard limit and it *must* be the device to drop this traffic. But to your point, any properly designed protocol is responsible for detecting this condition and throttling the source to relieve the problem.

Oh, and full-duplex is only available when connected to a switch (not a hub). These days you've really got to search to find hubs, but they're still out there.

Hans-Bernhard Broeker wrote in news: snipped-for-privacy@uni-berlin.de:

Now suppose the 10Mbit/s link is upgraded to 100Mbit/s and the Gbe link is feeding this port at 50Mbit/s. The 100Mbit/s MAC can now drain its packets out of the switch fast enough to keep the switch from back logging. The embedded product with the upgraded 100Mbit/s MAC may need to drop the packets but at least it won't bring the switch down.

Of course the system must be designed to ensure that the embedded product is not overrun if it can.

Richard wrote in news: snipped-for-privacy@azglobal.com:

Some popular switch chips have very limited packet memory. When used in an environment of bursty traffic to a port or two on the switch one might oversubscribe the switch memory. Everyone wins until the bursts hit all the ports and use up all the memory. An architectural flaw to be sure.

Seem I have to repeat this: I strictly refuse to accept that as an important case to be considered. In such a case the Gbe link is violating the original "10Mbit/s is enough" assumption, and behaving unreasonably. And why should we assume it stops at a mere 50Mbit/s, anyway? Why not do 300 Mbit/s?

Yes, a GBit line can flood the switch if it continues sending data to a single node faster than that node can accept them, regardless of whether that nodes is on a 100Mbit/s or 10Mbit/s line. Requiring that the switch not be allowed to become saturated or block packages in such a case is to ask the impossible. If a Gbit upstream node decides to behave unreasonably, nothing short of an all-Gbit network will be able to withstand it. So what --- should we take that to mean all embedded devices that have an Ethernet link must make that a

Not to mention there must be some serious flaw in the transport protocol if it allows the weaker endpoint to be flooded like that, without, e.g. the stronger one waiting for ACK packets or some other kind of 'clear to send' signal to come from it.