NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Ethernet auto-select and concurrent 10, 100 and 1000 connections



On 2019-02-02 23:14, Michael van Elst wrote:
tlaronde%polynum.com@localhost writes:

Is the speed adapted to each connected device? Or does the serving card
fix the speed, during a slice of time, for all connexions to the minimum
speed?

Autonegotiation means that the card and the switch communicate and
agree on a speed.


What is the "cost" of switching the speed or, in other words, is
connecting a 10base card able to slow done the whole throughput of the
card even for other devices---due to the overhead of switching the speed
depending on connected devices?

The speed isn't switched unless you disconnect or reconnect the
ethernet cable, but if the configuration is unchanged, card and
switch will usually agree on the same speed as before.


(The other question relates to the switch but not to NetBSD: does the
switch have a table for the connected devices and buffers the
transactions, rewriting the packets to adjust for the speed of each of
the devices?).

Almost all switches will allow to connect devices with different
speeds and packets that are received at one speed are buffered and
sent out at possibly a different speed. The packets don't need to
be rewritten.

Right. And I would say "all switches". That's essentially the difference between a hub and a switch. A hub just forward the bits in realtime, while a switch stores and forwards the packet. Packets are never rewritten, but a switch will have buffers, so it can handle different speeds on different ports.

Differences in speed between sender and receiver are usually handled
by higher level protocols (e.g. TCP) or by lower level protocols
(802.3x) when device and switch support it.

Well, in general, it is not "handled" at all. The packets are received by the switch at one speed, and sent out on a different port at a different speed. The two machines communicating will be unaware of the fact that they are actually communicating at different speeds. And the switch will just be using some memory, and introduce some small delay.

The one problem is when the switch is running out of memory. For example, if a machine runs a 100 Mbit/s link, and is producing data at full speed, and it needs to be forwarded on a 10 Mbit/s port. But that's simply a case of the switch then just dropping the packets.

A more clever switch will utilize random early drops (RED), which potentially have less impact on TCP connections than just outright drop all packets when the switch is really out of memory. But all of that is just attempts at protocol performance improvements based on knowledge of how TCP reacts to dropped packets.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


Home | Main Index | Thread Index | Old Index