Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp
Path: utzoo!linus!decvax!decwrl!sun!l5!gnu
From: gnu@l5.uucp (John Gilmore)
Newsgroups: net.works
Subject: Re: Sun 50 <--> VAX problems
Message-ID: <183@l5.uucp>
Date: Tue, 8-Oct-85 03:02:12 EDT
Article-I.D.: l5.183
Posted: Tue Oct  8 03:02:12 1985
Date-Received: Thu, 10-Oct-85 06:06:41 EDT
References: <3666@dartvax.UUCP>
Organization: Ell-Five [Consultants], San Francisco
Lines: 16
Summary: Maybe the Vax Ethernet interface is too slow.

One problem that earlier Suns had with talking to newer Suns is that
the newer Ethernet boards (Sun Ethernet Multibus board, and all VMEbus
systems), using VLSI Ethernet chips, can transmit back-to-back
packets.  The older boards (3Com) only have two receive buffers, and
once they fill, until the CPU responds to the interrupt and copies them
out, you drop packets.  This is aggrevated by each broadcast packet
filling one of the two buffers in every 3Com board on the net, making
it much more likely that later (broadcast or directed) packets would
get dropped.  The problem is further aggrevated in the Sun-3 since the
data in the packets is generated much faster in the first place.

I heard in earlier years that none of the Vax Ethernet boards was very
good (though I never worked with one so can't verify it).  Once TCP has
to go into retransmissions, the thruput goes WAY down, since it's tuned
for the claimed 99++% reliability of Ethernet.  (I haven't seen a
production Ethernet that gets 99++% of the packets through, though...)