A lot of what Maddog wrote pertains more to coax or hub based Ethernet
(CSMA/CD, Carrier Sense, Multiple Access with Collision Deterction) which is
"true Ethernet." Twisted pair media used with switches and routers I
believe is all Single Access and has no collisions.
> If I remember correctly, after a packet comes across, the controller is
> supposed to wait some period of time before grabbing the wire again.
I've never learned much about Twisted Pair. This is true for coax, and
probably true for Twisted pair. I've even forgotten the name of that delay,
something like interframe gap. I think one thing it does is allows
transceivers with slightly different clocks to keep the packets distinct.
On CSMA it helps give other stations a chance to get a word in edgewise.
You said that. On 10Base-2, the classic 10 Mbps Ethernet, the gap is 10
usec, 100 bits. It may be the same on 100BaseT, I think 1000BaseT it had
to be reduced.
> AFAIK it was accepted and anticipated that an ETHERNET controller was
> never going to effectively move wire speed at any given time onto or off
> of the disk.
I think it was worse than that - for a long time an accepted rule of thumb
was that an Ethernet should average over no more than 10% of full bandwidth
with peaks of 50% or so to keep the collision rate low. There's more to
getting access to the wire than just that interframe gap. People were
rather surprised to find it worked pretty well at much higher rates, it
turns out that a high collision rate doesn't impact throughput much, each
costs only 51 usec. One odd effect that is a spinoff of the collision
avoidance mechanism is the "capture" effect. If a station wants to get the
wire and collides with another station, each backs off a random amount up to
2 raised to the number of collisions times 51 usec or so. When one station
does get the wire, its backoff counter resets to zero and it has a better
chance of getting the wire at the next collision. This can lead to one
system getting a disproportionate amount of time on the wire. DEC even
identified some cases where groups of systems, each incapable of saturating
the wire could together and would form ephemeral gangs that captured the
wire.
With the advent of switches that buffer frames, most Ethernet installations
are no longer true ethernet, and most of the issues of capture effects and
collision issues have gone away, but have been replaced by problems with the
buffering being woefully inadequate. A Linux-based router will have plenty
of buffering, but routing 100 byte frames on multiple GbE wires would be
"interesting" (100 bytes == 800 bits == 800 nsec.) It took my all-time
favorite computer 13,500 nsec to divide a pair of 36 bit numbers (the first
PDP-10). At least it had a divide instruction. On a lot of modern
architectures your lucky to have an approximation of the reciprocal of the
divisor to start with.
> Maybe engineering expectations have changed since the days of 10Mbit
> ETHERNET, but I do remember having those discussions with the
> engineering staff.
Lots has changed - going from 10 Mbps to 10 Gbps is that three orders of
magnitude change the paradigm event. That 51 usec collision time determines
the maximum size of an CSMA/CD network. You want to have a colliding
packet be on the wire long enough so that both stations see the collision.
Scaling that down as speeds go up would mean a 10 Gbps network would
be 1/1000th the physical size of ye olde 10 Mbps network. Keeping the
collision time the same would mean giving up 1000 times more bandwidth,
which is enough to be a problem on busy nets. And on top of all that,
CSMA/CD is shared, and people are more concerned about security these
days. And since the cost of routers and switches has come down lots,
they now rule the office. Ethernet is dead - long live Ethernet
> And I agree that if you want to have the fastest path to your disk,
> having a bus that can support it is a place to start, no matter what
> ETHERNET controller you have.
Big battery backed caches are important too, at least if you want to trust
the data on your server. A UPS that provides power for the server to write
all cached data is adequate too.
-Ric Werme
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
