> On May 3, 2016, at 7:15 PM, Hittner, David T (IS) <[email protected]>
> 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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
