21 Sep
2008
21 Sep
'08
5:39 p.m.
On 9/18/2008 01:04 PM, cctech-request at classiccmp.org wrote:
Date: Wed, 17 Sep 2008 11:21:02 -0400
From: Paul Koning <Paul_Koning at Dell.com>
Subject: Re: OS/2 Warp, was Re: PCjr Telnet Server Test - Done!
To: cctalk at classiccmp.org
Message-ID: <18641.8286.275784.301355 at gargle.gargle.HOWL>
Content-Type: text/plain; charset=us-ascii
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.
Once a packet was received, you had to wait until software retrieved
the packet and re-enabled the card, before you could get the
next. Likewise if you wanted to transmit - you had to disable
reception, copy the transmit packet into the card, and then send
it. In PCs of that era that was a substantial chunk of time
relative to the potential arrival rate of 10Mbs Ethernet.
I have a presentation I have given at DECUS, where I analyzed (on
paper) what the likely best possible rates for an XT or PC-AT would
be. I should scan that in. (highly unlikely I have a machine
readably copy! wonder what I prepped that in?)
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.
With respect to DECnet, the problem came up quickly when we started
having PCs make requests from PDP-11 or VAX file servers, using
either FAL or the PathWorks server. When pushing data the mini
computer could quickly over run the slow PC with a dumb Ethernet
card. The rest of the world noticed when TCP/IP implementations got
good enough to encounter similar problems with FTP pulls, and PC file
servers finally got enough aggregate clients.
The workaround in DECnet-DOS was a careful tuning of the buffer pool,
and the transport (NSP) credit flow control window algorithms. The
delayed-ack mechanism was optionally tweaked to send an ACK
immediately upon receiving a packet ahead of the expected next. This
typically indicated a lost packet, and usually generated an immediate
retransmit.
The VAXmate and PCs using the DEPCA card would run rings around these
other cards. Because they used the AMD LANCE Ethernet chip with
multiple packet buffers in a mapped memory buffer. The DECnet-DOS
kernel optimized this by using it directly for it's buffer pool and
removing the need for another memory to memory packet copy.
With all due respect Paul, I've never asked another DECnet
implementation to "slow down", certainly not DECnet-RSTS. But don't
get me started on the VMS implementation of async DDCMP.
Dave (Mr. DECnet-DOS)
>>>> "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 
21 Sep
21 Sep
5:47 p.m.
New subject: Single buffered Ethernet adapters Was: OS/2 Warp, was Re: PCjr Telnet Server
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.
...
With respect to DECnet, the problem came up quickly when we started
having PCs make requests from PDP-11 or VAX file servers, using
either FAL or the PathWorks server. When pushing data the mini
computer could quickly over run the slow PC with a dumb Ethernet
card. The rest of the world noticed when TCP/IP implementations got
good enough to encounter similar problems with FTP pulls, and PC file
servers finally got enough aggregate clients.
The workaround in DECnet-DOS was a careful tuning of the buffer pool,
and the transport (NSP) credit flow control window algorithms. The
delayed-ack mechanism was optionally tweaked to send an ACK
immediately upon receiving a packet ahead of the expected next. This
typically indicated a lost packet, and usually generated an immediate
retransmit.
...
With all due respect Paul, I've never asked another DECnet
implementation to "slow down", certainly not DECnet-RSTS. But don't
get me started on the VMS implementation of async DDCMP.
Dave (Mr. DECnet-DOS)
I wasn't in DECnet/E at the time... But I remember a discussion in the DECnet
architecture group about the notion of having a "slow mode" for single buffered
adapters. I don't remember where it came from, I guess not from you, but I don't
think I'm imagining this. In any case, the idea went nowhere because it can't
work: even if a single node sends one packet at a time, that doesn't protect you from
a multicast from another node, or coincidences like that.
Paul
22 Sep
22 Sep
1:56 a.m.
New subject: Single buffered Ethernet adapters Was: OS/2 Warp, was Re: PCjr Telnet Server
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
2:18 a.m.
New subject: Single buffered Ethernet adapters Was: OS/2 Warp, was Re: PCjr Telnet Server
Ethan Dicks wrote:
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.
I think the DEQNA was DEC's first Qbus ethernet card. It certainly had
some "issues" and I think that was a known one. I don't think it could
be fixed, although I recall some version of VAX/VMS had a work around of
sorts that allowed recovery (some SYSGEN parameter could be set to
enable this recovery). The DEQNA was the first ethernet adapter for
which
VMS dropped support. I think this happened when the FFS driver interface
came along. I presume that DELQA and DELQA-YM fixed all this up - I
don't recall any complaints about those.
Exactly. The same was true for small VAXen, from what
I saw.
I wasn't sure what that meant in context.
If it meant that small VAXen (of the time) couldn't generate enough
traffic
to flood an ethernet, I think that's true. The DTJ article about the
DEMNA
(or the XMI ethernet interface, in case I've misrememberd the name!)
said
somewhere in it that it was the first DEC ethernet adapter that could
sustain
maximum ethernet xfer rate.
If it meant that other small VAXen could not cope with back to back
packets,
then I doubt that that is true. DEC did usually try to improve things as
time
went by :-)
Antonio
2:05 a.m.
New subject: Single buffered Ethernet adapters Was: OS/2 Warp, was Re: PCjr Telnet Server
Dave Mitton wrote:
With all due respect Paul, I've never asked
another DECnet
implementation to "slow down", certainly not DECnet-RSTS. But don't
get me started on the VMS implementation of async DDCMP.
I don't think that async DDCMP 9for Phase IV at least) fell into my
purview,
but I still have to ask ....
Antonio
arcarlini at iee.org
5936
days inactive
5936
days old
4 comments
4 participants
participants (4)
-
arcarlini＠iee.org -
dave＠mitton.com -
ethan.dicks＠usap.gov -
Paul_Koning＠Dell.com