[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