21 Sep
2008
21 Sep
'08
8:47 p.m.
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