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 _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
