22 Sep
2008
22 Sep
'08
1:56 a.m.
On Sun, Sep 21, 2008 at 08:39:31PM -0400, Dave Mitton wrote:
On 9/18/2008 01:04 PM, cctech-request at
classiccmp.org wrote:
This sounds familiar, but not in terms of ISA NICs... ISTR some
sort of similar issue with the DEQNA. Some of my friends in the
Ohio State University CIS program "enhanced" some networking code
on one or more of the UNIX servers in their group to the point
that it could slam out 2-3 back-to-back packets before going back
to gulp up more data to transmit. The problem was that someone
else in the group had a MicroVAX that would reliably crash when
this happened. IIRC, it was determined that the DEQNA couldn't
juggle a received packet while a new one was coming in. I can't
confirm that it's a single-buffered issue, but it sounds like it
fits the symptoms.
In the end, they had to rip out some if not all of their
enhancements because equipment of the mid-1980s was expecting
all the hosts to be so slow that there would always be time
to deal with one packet before the next came in.
Obviously later, things changed, but in 1986 or 1987, that
wasn't a fatal assumption.
From: Paul Koning <Paul_Koning at Dell.com>
The problem with the 3C501 (and the InterLAN and Ungermann-Bass, and
other I've forgotten about) Ethernet cards of this era where that
they only had one packet of memory on them. >>>> "Ethan" == Ethan Dicks
<ethan.dicks at usap.gov> writes:
Ethan> Back when NIC weren't $10 each, I remember the easiest to work
Ethan> with (in terms of compatibility) were the NE2000 and clones
Ethan> (NE1000 for 8-bit machines), the WD (later SMC) 8013, and the
Ethan> 3C501, later displaced by the 3C509. ...
Something to keep in mind is that the 3C501 is an extremely bad
design. It is completely incapable of dealing with back to back
packets -- even just two of them. And of course that's a perfectly
normal situation in any plausible network.
I remember working on DECnet when these toys came around, and the
request came in to have a "go slow" feature in DECnet to support this
single buffered design. The answer, of course, was "NFW". (Slowing
down at the source wouldn't have helped because the network could
easily cause clumping anyway...)
paul NetWare and NetBEUI driven networks hardly noticed
this problem for
two reasons: 1) they were Request/Response protocols. They normally
did not expect additional packets until they responded, and 2) they
were talking to other PCs. Which simply couldn't generate traffic fast
enough.
Exactly. The same was true for small VAXen, from what I saw.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 22-Sep-2008 at 08:40 Z
South Pole Station
PSC 468 Box 400 Temp -70.6 F (-57.0 C) Windchill -114.6 F (-81.5 C)
APO AP 96598 Wind 17.4 kts Grid 26 Barometer 676.5 mb (10761 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html