[Simh] Losing Time In SIMH

[Mark Pizzolato]

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.

- Mark