Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!ARAMIS.RUTGERS.EDU!hedrick
From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: maximum Ethernet throughput
Message-ID: <8803100444.AA08711@athos.rutgers.edu>
Date: 10 Mar 88 04:44:38 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 18

I thought it was obvious that I was talking about systems designers,
not the people who made up the Ethernet specs.  As I said, when we get
into untests realms, such as 8Mb single transfers, we run the danger
of finding bugs in the controller, its microcode, device drivers, and
possibly even (though we will hope not) the protocols defining the
Ethernet encapsulation for IP, DECnet, or whatever.  We see very
clearly the fact that many controllers can't handle bursts of packets
with minimum spacing.  Normally however they simply drop packets, not
crash the machine they are running on.  I have no idea why DECnet
machines would crash during bursts of TCP traffic (or even whether
that rumor is true), but I would start looking at the design of the
Ethernet controller and the device driver that is dealing with it.  It
could be something as simple as a bug in the code that handles
situations where you are unable to get the Ethernet for an extended
period of time, or something as complex as implicit assumptions in
some piece of the DECnet protocol design.  Of course it could also be
a bug in the Sun that causes it to fail to defer to someone else when
it is supposed to do so, but I sort of doubt that, since that should
be handled by the Lance chip.