[Simh] EXT :Re: RSTS and slow DECnet operation in SIMH

[Paul Koning]

> On May 3, 2016, at 7:15 PM, Hittner, David T (IS) <david.hittner at ngc.com> wrote:
> 
> Many of the older OS systems create rather small buffers for Ethernet packets, and do not handle the fast real-time receive rates of 100Mbps and 1000Mb Ethernet in the simulators very well.
> 
> This was due to:
> 	1) the OS expectation of being able to service the (maximum, never seen) Ethernet 10Mbps/sec buffered packets within the time frame allowed
> 	2) the OS expectation that packets not buffered (dropped) would eventually be retransmitted at some point by delivery protocols, which have an implied ACK/NACK delay
> 	3) Limited physical memory was available for Ethernet packet buffering.
> 
> Simulator speeds (for PDPs and VAXen) and modern network speeds are so fast compared to the original hardware that frequently the OS Ethernet buffers are just too small for efficient network packet processing. OS-side inefficiency can be addressed by patching the OS with larger Ethernet buffers. Emulator-side inefficiency can be fixed by "limiting" the Ethernet emulation speed by throttling it down to a speed more appropriate to the OS buffer processing rates. But this may cause extra dropped packets, which will likely be "fixed" by protocol retransmission.

Yes, those are all good points.  The RSTS case is different in that it is arguably a bug in the original -- but one that probably wasn't triggered with the combinations of machine and link speeds in the real hardware.  The design intent definitely was that (a) none of the network requests stall but instead return a "busy now" (or "no data now" for receive); (b) if the program is sleeping, any event that means "if you retry the network request it will now succeed" will wake it up.  And the issue is that, for this particular case, (b) was missing.

	paul