Subject: Re: SS20 network performance, take 2
To: <>
From: David Laight <david@l8s.co.uk>
List: port-sparc
Date: 05/26/2002 18:48:29
On Sat, May 25, 2002 at 05:52:44PM -0400, der Mouse wrote:
> Actually, a true hub has even less latency than a layer-2 switch.

True, they also cannot drop packets so are actually better in
many ways that a store+forward hub (which has terrible problems
if the target lan segment is 100% loaded...)

> Switches have to receive at least the first 48 bits of the data (the
> Ethernet destination address) before they can tell what port(s) to
> forward the packet out, meaning a delay of at least 48 bit times,
> probably more because of channel seizure and suchlike goop.

Also beware that some of the early 10M switches (probably in the
hands of 'normal' people now) would actually discard the packet
if the target port was busy, rather than reverting to 'store
and forard' or generating a collision.

> A true
> hub, on the other hand, just blindly echoes carrier, introducing only
> as much delay as is incurred by demodulating and remodulating - perhaps
> on the order of a couple of bit times, and doesn't care about channel
> seizure leadins and such - indeed, it could be argued that it's fair to
> call it a layer-1 device.

The delay is often quoted in metres - ie the length of cable that
would have the same delay.
> 
> Of course, most (layer-2) switches can be set for store-and-forward
> rather than cutting over immediately after the Ethernet destination MAC
> address (and early cutover works only when both ports are at the same
> speed anyway).  This will increase latency, of course, but if your
> network suffers from a lot of collision fragments, jabbers, etc, it can
> be worthwhile to do so, and many people do.  There's also latency
> introduced if the destination port is busy when the switch would like
> to send to it, though this "can't happen" under certain common
> conditions (only two hosts involved, running full-duplex at the same
> speed, with the switch never sending packets on its own initiative).

I believe (hope) that most modern switches will attempt to avoid
dropped packets.  On HDX links the switch can generate a collision
if there is no space to store the packet it is receiving (but I've
not seen an ethernet chipset with this feature).  The FDX protocol
also has a mechanism (IIRC modulating the link test pulses) for
the target to indicate it has no buffer space.

OTOH I've never seen the amount of buffer space quoted, nor
whether it associated with the input or output device.
FTP and NFS need massive buffering if you need to change from
100M to 10M (or from an idle LAN to a busy one).

The other type of device that will link two lan segments is a
'repeater' set.  This links two coax segments keeping them in
the same collision domain (you might see 8 or more port ones),
these all (ok all the ones I've seen) require that the
transceivers used disable the SQE test (a burst on the AUI
collision line just after the end of transmission that
tests the tx path and collicion path on the AUI link).  If
SQE is left enables the repeater treats it as a collision and
genereates a 'collision jam' signal on the input side - which
will generate a real collision if the source sent back to
back frames.  This seriosly kills performance :-)
Repeater sets also require high tolerance transceivers that
can do 'receive mode collision detect'....
NB these are AUI-AUI or coax-coax boxes, and not the AUI
'fan-out' boxes which allow (typically) 8 computers to be
connected to one tap - which are much more like UTP hubs.

	David

-- 
David Laight: david@l8s.co.uk