On 2017-01-31 21:07, Mark Pizzolato wrote:
On Tuesday, January 31, 2017 at 11:29 AM, Johnny Billquist wrote:
On 2017-01-31 06:34, Sergey Oboguev wrote:
It has been a long while since I touched SIMH, but when I did in the
3.9.x timeframe (and I do not know if the design has changed since
then), I made the following note:
/... the tendency of SIMH idea of system time (such as OpenVMS system
time, when OpenVMS is executed on SIMH) to fall behind wall clock time.
This “falling behind” happens because of a number of [...] reasons:
host timer events are fired later then requested; it takes time for
the hibernating thread to resume and start tracking time; accumulating
///rounding /errors ///in /time data obtained from the host, SIMH
timing mechanisms dependence on the VCPU calibration (i.e.
instructions per second rate) which is subject to variations because
of a concurrent host load and also inherently – because of the
inherent variations in the composition of the executed instruction
set, page faults, synchronous IO operations executed on the VCPU
thread etc.; because of OpenVMS suspension while SIMH console is in
use or ROM console is in use; because of OpenVMS suspension while host
system was suspended and similar reasons./
I would suspect the cause is because imprecise time handling in a user process
on the host OS. However, that can be managed and corrected for, so it
depends on how simh actually have implemented this in the end.
If simh is clever, it checks the wall clock from time to time, to see if it is
drifting, and increases the rate of the simulated clock in that case. What it
cannot do is just fire several clock interrupts in a row, since most hardware do
not handle multiple interrupts from one source queued up, nor clock
interrupts happening when the interrupt handler is already running to process
the clock interrupt.
I guess Mark or Bob could answer how simh deals with time slippage due to
host OS scheduling effects.
FYI. This discussion has moved to https://github.com/simh/simh/issues/390
Simh tracks and adjusts for wall clock behaviors quite reliably. The problem
here
is that the OS is programming the interval timer device to generate ticks at
60Hz
and we don't have other common examples that do this on the VAX. It seems
like it is programming the interval timer register to -16667, and ticks per
second
is being computed to be 100000/16667 which ends up to be 59 rather than
60. This causes the very consistent calibration at 59Hz and therefore the
timing
results he is seeing. On this and other VAX7xx and VAX8600 systems, most OSes
use a 100Hz tick and an interval register of -10000 which doesn't suffer from
the
same rounding problem. The original user (Jason Self) is testing an appropriate
change right now.
Hum. I hate moving discussions... :-)
Anyway, I'm surprised by the interval timer. I had a recollection that
it was normally always at 100Hz on VMS. Oh well. I wonder why on earth
you would want to have a 60Hz clock here...
PDP-11 (and I suspect PDP-10 and other older machines) are a different
story, as they usually use the line frequency of the mains AC as the
clock source, which means 60Hz in the US.
(On a side note, until the electric companies stopped caring about exact
line frequency, my PDP-11s were the most accurate time keepers I knew...)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
