[Simh] idle feature

[Mark Pizzolato]

So on your system the clock_getres() API seems to be failing.  Since
my test program didn't check the return status from clock_getres() it
proceeded to perform calculations on the random uninitialized stack
variable, so the output was meaningless.

I can't honestly say what the consequences of your hack would be.

I originally implemented IDLE support for simh, and I gave that
implementation to Bob for inclusion.  Bob took the general idea and
reimplemented it his own way.

In my implementation I did not use clock_getres() to determine the
host clock resolution, I did a platform independent brute force
"observation" of the clock resolution (done once at init time):

if (0 == rtc_clockres) {
	rtc_clockres = 0x7fffffff;
	for (i=0; (i < 30) && (rtc_clockres > 1); ++i) {
	    uint32 lclock, nclock;
	    lclock = sim_os_msec ();
	    while (lclock == (nclock = sim_os_msec ()));  /* Wait for clock
tick */
	    if (rtc_clockres > (nclock-lclock)) rtc_clockres =
(nclock-lclock); 
        }
	rtc_sleepgran = sim_os_msleep(rtc_clockres);  /* Aligns  to a sleep
tick boundary */
	slept = sim_os_msleep(1);  /* Now observe sleep tick size */
	if ((slept > 0) && (slept < rtc_sleepgran))
            rtc_sleepgran = slept;
	for (i=0; i <= 2*rtc_clockres; ++i) {
	    slept = sim_os_msleep(1);
	    if ((slept > 0) && (slept < rtc_sleepgran))
                rtc_sleepgran = slept; 
        }
}
The above code would run for up to 332ms on a system with a 10ms
clock tick and 32ms on a system with a 1ms clock tick.  I thought
this was acceptable startup behavior.

The mechanisims I used to determine when and how long to sleep were
completely different as well.  In my case you could always try to
enable idling (it would never fail), however, your platform's
resolution of timing (sim_os_msec()) and/or sleeping
(sim_os_msleep()) might not be good enough to allow any sleeping to
happen since the primary goal was to IDLE when the guest VAX was was
truly idle and to keep simulator events/interrupts correctly
happening in a timely manner (Minimizing simulated clock drift,
etc.).

Bob's idling implementation dovetails into the throttling
implementation which I didn't do.

Rather than fudging the answer to the clock tick size as you did, you
might give my brute force method a try and see if idling actually
works, and determine what your clock tick size actually is.

It also might be interesting to determine what errno is on your
system when clock_getres() fails.

- Mark

--- "Bailey, Scott" <scott.bailey at eds.com> wrote:

> Mark, I tried your program.
> 
> On my system (AMD Athlon 64 dual core 4200+, Debian's
> linux-image-2.6.24-1-amd64), I get:
> 
> Close Resolution: 0 msec, 1 nanoseconds
> 
> Looking at sim_timer.c, I see the test you are talking about... But
> of
> course, it appears that "0" [msec] is overloaded to mean that
> sim_os_ms_sleep_init() failed and I presume that idle support is
> thereafter disabled. :-) Evidently high-resolution clock support is
> not
> always a good thing!
> 
> I hacked the code at this point [sim_timer.c, line 306] to replace:
> 
> 	return msec;
> 
> with
> 
> 	if (msec)
> 	    return msec;
> 	else
> 	    return 1;
> 
> and that seems to have magically enabled the set cpu idle command
> again.
> I haven't fired up the simulator yet to see if it really seems to
> be
> WORKING or not yet, but I am hoping that using an interval higher
> than
> what the system supports won't be a problem.
> 
> Advice on whether this is the smartest thing to do -- i.e., would
> it be
> more effective to use a higher value and avoid thrashing the timer?
> --
> would be appreciated.
> 
> Thanks,
> 
> 	Scott
> 
> -----Original Message-----
> From: simh-bounces at trailing-edge.com
> [mailto:simh-bounces at trailing-edge.com] On Behalf Of Mark Pizzolato
> Sent: Friday, February 08, 2008 11:37 AM
> To: SIMH Mailing List
> Subject: Re: [Simh] idle feature
> 
> [...]
> 
> The simulator uses clock_getres() to determine the size of the
> clock
> tick.  It then performs the following calculation to determine the
> size of the tick in milliseconds:
> msec = (treq.tv_nsec + (NANOS_PER_MILLI >> 1)) / NANOS_PER_MILLI;
> this should round the number of nanoseconds up to the closest
> millisecond and come up with the millisecond value.  If the result
> is
> greater than 10, then idling is disabled.
> 
> I don't know of a command line program which calls and displays
> clock_getres(), but you could compile the below one.  Once you have
> that you can test to see if the "adjtimex -t 9999" changes the
> value
> returned by clock_getres().
> 
> #include <time.h>
> #include <stdio.h>
> #define NANOS_PER_MILLI     1000000
> main(int argc, char **argv)
> {
> struct timespec treq;
> uint32 msec;
> 
> clock_getres (CLOCK_REALTIME, &treq);
> msec = (treq.tv_nsec + (NANOS_PER_MILLI >> 1)) / NANOS_PER_MILLI;
> printf ("Close Resolution: %d msec, %d nanoseconds\n", msec,
> treq.tv_nsec);
> }
> 
>