[Simh] [Simh-dev] Idling around

[Mark Pizzolato]

--- Bob Supnik <bob at supnik.org> wrote:

> Some progress at last on idle, thanks to pointers and code from
> Bruce Ray and Mark Pizzolato.
> 
> I have a trial implementation of idle for the PDP-11 running.  On
> an OS that uses the WAIT instruction, it idles at very close to 0%
CPU
> 
> utilization, according to XP's usage meter, and maintains accurate 
> time.  At the moment, it is WIndoze only, and it has some
> reliability issues.
> 
> 1. The code uses the multimedia timers, and for some reason, they 
> don't seem to engage right away.  After setting a time period of 1 
> msec, the first couple of Sleep (1)'s can sleep for up to 16ms; 
> thereafter, everything seems to work okay.  I'm still experimenting
> to see what's going on here.
> 
> 2. I need implementations of
> 
> 	t_bool sim_os_sleep_ms (unsigned int milliseconds)
> 
>   for VMS, Mac/OS, Unix (BSD), and Linux.  I <think> that VMS 
> (Alpha), Mac/OS, and Linux can all use nanosleep, while VMS (VAX)
> and 
> Unix (BSD) can use usleep; but I'd like someone with access to the 
> real systems to code up and compile the functions, figure out the 
> correct include headers and so on.  There's an auxiliary, called
> once function
> 
> 	t_bool sim_os_sleep_ms (void)

The code I sent you provided ms granularity sleeps for most relevant
platforms.  These have been tested on VMS, BSD, Linux and Solaris. 
The select() based implementation seemed to be better and more
portable than relying on usleep(), which when I tested it seemed to
have more overhead (at least on one platform).

The code I sent you also calibrated the local scp's view of the host
system's capabilities:  the system clock timer resolution, and the
actual sleep resolution (I think).  The running simulator attempted
to tolerated weaker sleep resolution by trying to catch up on missed
events after sleeps, and choosing not to sleep if the time to sleep
was less than 1/2 of the system timer resolution.

Maybe my calibration efforts masked your observations about the first
couple of sleeps being of longer duration.

> if you need to initialize something (Windows requires a set up 
> call).  The return value for both is whether the sleep function 
> exists; true if it does, false if it doesn't.
> 
> 3. I need to implement global controls for turning idle on and off,
> and to minimize the arithmetic that's used in the idle computation,
> which can be extensive.

Surely, this can't matter much if you are only doing it when the
simulated CPU could actually be idling.

> 4. Then, each simulator will need a simulator specific idle 
> algorithm.  For the PDP-11, it's the WAIT instruction (which won't 
> work for RT11, I believe); for the Interdata systems, it's wait 
> state.  For the PDP-8, PDP-15, H316, and GRI-909, I'm proposing to 
> use the standard keyboard wait loop:
> 
> 	KSF/JMP *-1 or its equivalent
> 
> as the idle loop.
> 
> 5. For the VAX, as discussed, it's any prolonged execution at IPL's
> 0 through 3 in kernel mode.  This covers the idle loops of 
> VMS, NetBSD, and OpenBSD, but not, alas, Ultrix, which hops up 
> to IPL 18 periodically.

I've tested this for all of the above OSes, which seemed to work
fine, and provided the details of the relevant conditions, including
the Console ROM code when I sent you the hint about MMtimers.

> 6. For systems without I/O delays (1401, 1620, LGP-30), idle would
> be waiting on the keyboard, since all other I/O operations finish 
> instantly.  I haven't looked into the 7094 yet.
> 
> 7. The current algorithm will not support the DEC-10, because the 
> KS10 has timer interrupts at <1msec intervals, which is the minimum
> granularity for wait.  "Bunching up" the clock interrupts is beyond
> the scope of the current work.

The best you can do is to try hard to get the clock stuff "right",
but since most folks will be running on non-dedicated hardware, there
will always be quite variable drift.  The same problem exists in the
various PC emulation/Virtual environments today.  MS Virtual PC, and
MS Virtual Server, and VMWare all have special "software" packages
that you install in the simulated computer's OS which talk to the
simulator directly to facilitate proper time keeping, mouse tracking,
etc.  Anternatively, I've run a standard NTP based cron job which
syncs the simulated system's clock to an outside source every 10
minutes.

> Note that idling is different from throttling.  Throttling would 
> basically stall execution every 'n' instructions, regardless of 
> whether the system was busy or not.  On systems with clocks, this
> has to be coordinated with the way the clock counts and calibrates,
> or wall-time tracking will be disrupted.  On systems without 
> clocks, stalls can inserted arbitrarily.

Agreed.

- Mark Pizzolato