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

Sat Mar 30 00:41:15 PDT 2019

Dear Jack,

I wonder if you had that problem with a mix of 3COM, NE2000 and NE2000
compatible cards on the same network.
Having started with Novell & 3COM cards, all on Coax, we found that we
started getting timeouts when we added more cheap NE2000 compatible cards.
Did the same thing with oscilloscopes/analysers and tweaked parameters
to go around this problem.
Warm regards,

Olivier

On 30/03/2019 02:57, Jack Haverty wrote:
> 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
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20190330/b2994cc2/attachment.htm>