[HECnet] Booting VMS 5.5.2 cluster satellite node [SIMH 4.0] over slow link

[Vladimir Machulsky]

> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf
> Of Mark Pizzolato - Info Comm
> Sent: Monday, September 28, 2020 11:15 PM
> To: hecnet at Update.UU.SE
> Subject: RE: [HECnet] Booting VMS 5.5.2 cluster satellite node [SIMH 4.0]
over
> slow link
> 
> Fantastic detective work, and it is certainly amazing that you got this
far.
> 
> If throttling affects the results, then it seems to me, that the SCS
> capabilities (which PEDRIVER leverages) aren't using anything which tracks
> with the wall clock to measure delays.  I suspect that where the SCS layer
is
> "thinking about"
> timing stuff it is using the TIMEDWAIT macro in the kernel/driver code.
> As I recall, TIMEDWAIT effectively uses a processor model specific value
> spinning until the presumably appropriate amount of time has elapsed.
> Since most simh host systems actually run significantly faster than the
> original hardware did, these TIMEDWAIT macro invocations don't track with
wall
> clock time very well.  The VAST majority of TIMEDWAIT uses in VMS drivers
> relate to the CPU interacting with a device which is internal to the
> simulator.  SIMH interactions with devices is measured in instructions
(which
> aligns well with the internal implementation of the TIMEWAIT macro).
> 
> I vaguely recall that DEC had conceptual support for clusters which were
> located at physically different sites, but which were connected by
relatively
> high speed and low latency network connections.  I believe that the
> "supported" configurations were much faster and much lower latency than
your
> setup is seeing.
> 
> Good Luck,
> 
> - Mark

After a series of experiments, it became apparent that the behavior of SCS
boot part is 
really depends on the emulated VAX hardware model.
Thank you for valuable information, Mark!