[ih] Internet History - from Community to Big Tech?

[Jack Haverty]

I can confirm that there was at least one Unix vendor that violated the
Ethernet specs (10mb/s).  I was at Oracle in the early 90s, where we had
at least one of every common computer so that we could test software.

While testing, we noticed that when one particular type of machine was
active doing a long bulk transfer, all of the other traffic on our LAN
slowed to a crawl.   I was a hardware guy in a software universe, but I
managed to find one other hardware type, and we scrounged up an
oscilloscope, and then looked closely at the wire and at the spec.

I don't remember the details, but there was some timer that was supposed
to have a certain minimum value and that Unix box was consistently
violating it.  So it could effectively seize the LAN for as long as it
had traffic.

Sorry, I can't remember which vendor it was.  It might have been Sun, or
maybe one specific model/vintage, since we had a lot of Sun equipment
but hadn't noticed the problem before.

I suspect there's a lot of such "standards" that are routinely violated
in the network.   Putting it on paper and declaring it mandatory doesn't
make it true.  Personally I never saw much rigorous certification
testing or enforcement (not just of Ethernet), and the general
"robustness" designs can hide bad behavior.

/Jack Haverty


On 3/29/19 5:40 PM, John Gilmore wrote:
> Karl Auerbach <karl at cavebear.com> wrote:
>> I recently had someone confirm a widely held belief that Sun
>> Microsystems had tuned the CSMA/CD timers on their Ethernet interfaces
>> to have a winning bias against Ethernet machines that adhered to the
>> IEEE/DIX ethernet timer values.  Those of us who tended to work with
>> networked PC platforms were well aware of the effect of putting a Sun
>> onto the same Ethernet: what had worked before stopped working, but
>> the Suns all chatted among themselves quite happily.
> Are we talking about 10 Mbit Ethernet, or something later?
>
> I worked at Sun back then.  Sun was shipping products with Ethernet
> before the IBM PC even existed.  Sun products used standard Ethernet
> chips.  Some of those chips were super customizable via internal
> registers (I have a T1 card that uses an Ethernet chip with settings
> that let it talk telco T1/DS1 protocol!), but Sun always set them to
> meet the standard specs.  What evidence is there of any non-standard
> settings?
>
> What Sun did differently was that we tuned the implementation so it
> could actually send and receive back-to-back packets, at the minimum
> specified inter-packet gaps.  By building both the hardware and the
> software ourselves (like Apple today, and unlike Microsoft), we were
> able to work out all the kinks to maximize performance.  We could
> improve everything: software drivers, interrupt latencies, TCP/IP
> stacks, DMA bus arbitration overhead.  Sun was the first to do
> production shared disk-drive access over Ethernet, to reduce the cost of
> our "diskless" workstations.  In sending 4Kbyte filesystem blocks among
> client and server, we sent an IP-fragmented 4K+ UDP datagram in three
> BACK-TO-BACK Ethernet packets.
>
> Someone, I think it was Van Jacobson, did some early work on maximizing
> Ethernet thruput, and reported it at USENIX conferences.  His
> observation was that to get maximal thruput, you needed 3 things to be
> happening absolutely simultaneously: the sender processing & queueing
> the next packet; the Ethernet wire moving the current packet; the
> receiver dequeueing and processing the previous packet.  If any of these
> operations took longer than the others, then that would be the limiting
> factor in the thruput.  This applies to half duplex operation (only one
> side transmits at a time); the end node processing requirement doubles
> if you run full duplex data in both directions (on more modern Ethernets
> that support that) .
>
> Dave Miller did the SPARC and UltraSPARC ports of Linux, and one of his
> favorite things to work on was network performance.  Here's one of his
> signature blocks from 1996:
>
>   Yow! 11.26 MB/s remote host TCP bandwidth & ////
>   199 usec remote TCP latency over 100Mb/s   ////
>   ethernet.  Beat that!                     ////
>   -----------------------------------------////__________  o
>   David S. Miller, davem at caip.rutgers.edu /_____________/ / // /_/ ><
>
> My guess is that the ISA cards of the day had never even *seen* back to
> back Ethernet packets (with only the 9.6 uSec interframe spacing between
> them), so of course they weren't tested to be able to handle them.  The
> ISA bus was slow, and the PC market was cheap, and RAM was expensive, so
> most cards just had one or two packet buffers.  And if the CPU didn't
> immediately grab one of those received buffers, then the next packet
> would get dropped for lack of a buffer to put it in.  In sending, you
> had to have the second buffer queued long before the inter-packet gap, or
> you wouldn't send with minimum packet spacing on the wire.  Most PC
> operating systems couldn't do that.  And if your card was slower than
> the standard 9.6usec inter-packet gap after sensing carrier,
> then any Sun waiting to transmit would beat your card to the wire,
> deferring your card's transmission.
>
> You may have also been seeing the "Channel capture effect"; see:
>
>   https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_detection#Channel_capture_effect
>
> 	John
>
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.