29 Sep
2020
29 Sep
'20
1:10 p.m.
-----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!