[Simh] [Simh-dev] Beautiful theory meets ugly fact

[Kevin Handy]

Bob Supnik wrote:

>My trial implementation of idle for the PDP-11 seemed to work, but 
>there was one peculiar effect: some of the typeouts from the 
>operating system suddenly started having noticeable pauses between 
>characters.  Since the timeout for the console output was far shorter 
>than a calibrated millisecond ever should be, this made no sense.
>
>I dumped the calibrated clock values and sure enough, with idle on, 
>instructions per msec dropped from 70,000 to around 80, less than the 
>console output delay.  This made no sense, unless the waits being 
>done by idle were completely screwing up clock calibration.
>
>So I wrote a quick test program and discovered that, under Windoze, 
>the basic clock tick is 15msec and change, not 1msec.  This is 
>confirmed by various postings on the Web.  It's even worse under 
>early versions of (95 and 98), where the clock tick was on a 55msec 
>interval.  So the attempts to wait for 1-10 msec were all failing, 
>and the clock calibration values were getting badly skewed in order 
>to try to compensate.
>
>With a minimum 15msec wait under Windoze, the notion of waiting until 
>the next simulated event won't work, since on the VAX, the clock 
>ticks every 10msec.  The distortions introduced by WIndoze' long wait 
>in fact cause clock calibration to fail, and the simulator won't keep 
>accurate time.
>
>  
>
I'm not sure that Unix will give you an accurate 1ms delay
either in it's micro-sleep, but it should do better. The problem
is that the hardware clock-ticks don't start at the time you
call the sleep, so it may sleep somewhat longer or shorter.

(Calling it an "idle process" for lack of a better name)

Could you "batch-up" the "idle process"? Sleep for however long
you can, then allow the "idle process" to free-run for a number
of times based on how long you really slept? (After sleeping,
set up a counter that says to not-sleep the next X times the
idle process gets ticked, but act as if the time has passed) i.e.
if you sleep for 30ms, you can run the idle process 3 times
if it wants to run every 10ms, or 30 times if it wants 1ms.

I don't know if this would be more or less noticeable than
the slowdown you are seeing, but shouldn't be to hard to
code based on what I understand about your current
implementation.

>Back to the drawing boards.
>  
>