[Simh] Losing Time In SIMH

[Johnny Billquist]

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: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol