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

Villy Madsen Villy.Madsen at shaw.ca
Tue Sep 5 19:22:48 EDT 2006


You could take a look at the changes that I made to the VAX & PDP11 code to
allow for throttling.

It basically works as described below - sleeps for 1 count every so many
thousand instructions.  Seems to work fine on the VAX, I built the code into the
pdp-11 but never tested it...

Villy

Code available at

http://members.shaw.ca/villy.madsen/simh/  or

http://68.150.97.212/

-----Original Message-----
From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On
Behalf Of Kevin Handy
Sent: Tuesday, September 05, 2006 03:11
To: simh at trailing-edge.com
Subject: Re: [Simh] [Simh-dev] Beautiful theory meets ugly fact

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.
>  
>


_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh





More information about the Simh mailing list