What's in a jiffie?
Bob Supnik
to the hardware level, with a frequency of 1001Hz (reflecting the
slightly less than 1msec timing).
I'm about to add the ability to 'idle' to SimH, and one of the
prerequisites is that the clock events have to occur a lot less
frequenlty than the granularity of the host timer, which is typically
1msec. At the moment, the KS10 doesn't do that and woudn't be able to
idle.
Thinking about it, I realized that the KS10's operating systems
couldn't possibly be running their clock interrupts so fast - that
would be fewer than 300 instructions between interrupts. Sure enough,
looking through TOPS-10, I saw that timing is done in 'jiffies', which
appear to be either 16.67ms or 20ms, depending on the line clock.
Some questions:
1. Why did TOPS-10 vary the 'jiffie' with the line frequency, when, in
fact, the KS10 clock was independent of the line frequency? Is this a
carryover from some earlier systems?
2. What did TOPS-20 use for a clock tick interval?
3. What did ITS use for a clock tick interval?
And then on idle loops:
4. Is the TOPS-10 idle loop always a tight loop executed out of the
registers? Did this vary from release to release?
5. What's the idle loop in TOPS-20?
6. What's the idle loop in ITS?
Because the KS10 runs a relatively restricted set of OS's (TOPS-10
6.03A and 7-series, TOPS-20 4 series, and ITS), I'm hoping to come up
with a set of answers that will allow full implementation of the
simulator idle capability.
Thanks,
/Bob Supnik
John Sauter
>1. Why did TOPS-10 vary the 'jiffie' with the line frequency, when, in
>fact, the KS10 clock was independent of the line frequency? Is this a
>carryover from some earlier systems?
>
The "jiffie" was defined for the PDP-6, where the clock interrupt was
based on the power line frequency. In 60 Hz countries it was 16.67
milliseconds, in 50 Hz countries, 20. I was told that there was a
50 Hz generator in the Mill, powered by water, that was used for
the parking lot lights and to make sure that the 50 Hz hardware
and sofware would work.
John Sauter (J_Sa...@Empire.Net)
glen herrmannsfeldt
(snip)
I was told that there was a
> 50 Hz generator in the Mill, powered by water, that was used for
> the parking lot lights and to make sure that the 50 Hz hardware
> and sofware would work.
Incandescent lamps?
It must be hard to find 50Hz ballasts for mercury lamps around here.
-- glen
John Sauter
>
>Incandescent lamps?
>
>It must be hard to find 50Hz ballasts for mercury lamps around here.
>
>-- glen
I don't know what the technology of the parking lot lamps was
at that time, but consider this: the DEC culture of the 1960s
was based on electrical engineers out of MIT. I don't think
they would have had any trouble making ballasts for
50 Hz mercury vapor lamps had they been needed.
John Sauter (J_Sa...@Empire.Net)
Eric Smith
> 1. Why did TOPS-10 vary the 'jiffie' with the line frequency, when, in
> fact, the KS10 clock was independent of the line frequency? Is this a
> carryover from some earlier systems?
Yes.
The clock on the KA10 and KI10 is based on line frequency.
CONO APR, is used to control the clock and its interrupt:
bit 26, when 1, clears the flag
bit 25, when 1, disables the interrupt
bit 24, when 1, enables the interrupt
bits 33-35 select the clock interrupt priority level
CONI APR, is used to read the clock:
bit 6 is 1 if the system is configured for 50 Hz
bit 25 is the clock interrupt enable bit
bit 26 is the clock flag
bits 33-35 are the clock interrupt priority level
There is a separate DK10 real time clock option for higher resolution
timing (100 kHz crystal controoled, or an external source up to 400
kHz). It's accessed as device "CLK". I don't think the DK10 was generally
used for the jiffy clock, though it probably was used (if available) for
more precise accounting of process execution time.
Before there was high-resolution process accounting, there was a hack to
reduce the "cost" of compute-bound jobs, which was to have the job do
something that yields the CPU every so often, at less than a full tick
interval, e.g., perhaps every half tick or so. That way you often
didn't get charged for a tick. I've heard it claimed that DK10 sales
impoved quite a bit once this became well-known, but it was before my
time so I don't know firsthand.
The KL10 had a high resolution timer as a standard feature (part of the
"meter board").
Eric
glen herrmannsfeldt
(I wrote)
>>It must be hard to find 50Hz ballasts for mercury lamps around here.
> I don't know what the technology of the parking lot lamps was
> at that time, but consider this: the DEC culture of the 1960s
> was based on electrical engineers out of MIT. I don't think
> they would have had any trouble making ballasts for
> 50 Hz mercury vapor lamps had they been needed.
Ballasts are, or at least were not so long ago, combinations
of transformers and inductors, sometimes with saturating magnetic
cores to regulate the current. Design may not be so hard, but
building them requires a lot of metal work, and coil winding,
not so much actual electrical engineering.
-- glen
jmfb...@aol.com
My red flag is telling me that I'm going to fuck up this name...
There is a monitor module, CLOCK1.MAC, that may be useful to
Bob. I do no remember if the KA feature test switch code
was deleted or simply turned off permanently. The KI code
should still be there.
/BAH
bob.s...@sicortex.nospam.com
though 6. My quick look at TOPS-20 actually running seems to confirm
that it takes 1000 clock interrupts per second. I can't imagine what
that did to the performance of a real KS10.
/Bob
On Fri, 27 Oct 2006 14:01:48 -0400, Bob Supnik
<bob.s...@sicortex.nospam.com> wrote:
<snip>
>
>Some questions:
>
<snip>
John Everett
<bob.s...@sicortex.nospam.com> wrote:
>1. Why did TOPS-10 vary the 'jiffie' with the line frequency, when, in
>fact, the KS10 clock was independent of the line frequency? Is this a
>carryover from some earlier systems?
Funny thing, I can remember giving some thought to whether or not I
should implement separate jiffies for the two sides of the pond, but
don't recall my reasoning for having both the 60hz and 50hz versions.
I'm guessing it was probably just for symmetry. Certainly there seems
to be no technical reason.
jeverett3<AT>earthlink<DOT>net http://home.earthlink.net/~jeverett3
Christopher C. Stacy
> When I wrote the KS10 simulator, I modelled the timer at pretty
> close to the hardware level, with a frequency of 1001Hz
> (reflecting the slightly less than 1msec timing).
>
> I'm about to add the ability to 'idle' to SimH, and one of the
> prerequisites is that the clock events have to occur a lot less
> frequenlty than the granularity of the host timer, which is typically
> 1msec. At the moment, the KS10 doesn't do that and woudn't be able to idle.
> 3. What did ITS use for a clock tick interval?
ITS uses devices 20 and 24 for the 4.1 Mhz timer.
The "clock break" interrupt is set there to be
a traditional jiffy: KSFREQ==4100000./60
> 6. What's the idle loop in ITS?
It sticks a halt (JRST 4,) in ACs 1-16,
puts [AOJA 17] into 17,
and jumps there in user mode.
Mark Crispin
The Panda version of TOPS-20 idles the microcode at SCDNL2+5, just before
the JRST SCDNL2. Rather than analyze the idle loop, there is a machine
instruction. All KLH10 versions have it as CONO 700,1 but in the Panda
version of KLH10 it's quite a bit more sophisticated.
The microcode idle stalls the PDP-10 processor until the next interrupt.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Bob Supnik
1. The user would tell the simulator what OS is being run and thus
identify the basic clock frequency expected. Since the user already
has to identify ITS (for different microcode), and TOPS-20 (due to a
T20 boot bug), this is not a big deal. There would be four settings:
KLAD - run clock in diagnostic mode (fixed timing)
TOPS10 - the default - run clock at 60Hz (with an option for 50Hz)
ITS - run clock at 60Hz, always
TOP20 - run clock at 1001Hz
2. In TOPS10 and ITS modes, the simulator would look for the standard
idle loops and idle when they are seen.
I don't know if it's going to be possible to idle TOPS20, because the
minimum idle delay (1msec) is longer than the actual clock tick. The
special idle instruction won't work, because SimH runs old versions of
TOPS20 (V4 and maybe V5) which would have to be patched.
/Bob
glen herrmannsfeldt
(snip)
> I don't know if it's going to be possible to idle TOPS20, because the
> minimum idle delay (1msec) is longer than the actual clock tick. The
> special idle instruction won't work, because SimH runs old versions of
> TOPS20 (V4 and maybe V5) which would have to be patched.
I would say cheat, and supply a way for the TOD clock to get the
right time, even if clock interrupts stop.
-- glen
Bob Supnik
1) The clock service runs at 60Hz and delivers a clock interrupt at
that rate. (Yeah, if you gen'd a 50Hz T10 system, you're out of luck
for now). I've verified that TOPS-10, at least, still keeps accurate
time this way.
2) If ITS is running, and the simulator sees an AOJA 0,17 instruction
in location 17 in user mode, it attempts to go idle. This is the
standard ITS idle loop.
3) If TOPS10 is running, and the simulator sees a SOJG 6,1 instruction
in location 1 in user mode, it attempts to go idle. This is the
standard TOPS10 idle loop. I've verified that if TOPS-10 is idle,
this reduces CPU usage to < 5%.
Still thinking about TOPS-20. Idling could cause clock ticks to
appear to be only a handful of instructions apart. That's fine for
the 'fast path' through the clock interrupt handler but may not work
if the clock handler invokes the scheduler, and another clock tick
occurs immediately after that.
/Bob
Bob Supnik
be the following:
1) If TOPS20 is running, and the simulator sees a SOJG 2,3 in location
3 in monitor mode, AND the idle interlock isn't set, AND if there's at
least half a clock tick to go before the next simulated event, the
simulator waits 1 ms and then schedules the next event to happen
immediately.
2) When the clock event occurs, based on a programmable probability p,
the idle interlock is cleared.
Thus, p% of the idle clock cycles are done by waiting, and 100-p% are
counted. This allows clock calibration to 'shorten' the counted
cycles and keep accurate time, even though most of the clock cycles
are a little long.
With a probability factor of 66%, the host system's CPU usage falls to
33%, as one would expect, and TOPS-20 keeps accurate time. I'm still
experimenting with how far I can 'push' the probability slider before
accurate time keeping is lost.
/Bob Supnik
Mark Crispin
> 1) If TOPS20 is running, and the simulator sees a SOJG 2,3 in location
> 3 in monitor mode
That won't work after TOPS-20 4.1.
The in-AC wait loop in the ACs is gone as of TOPS-20 5, and it changed
again in release 6 and 7. In modern TOPS-20, the scheduler loops looking
for processes to become runnable (or other things to do).
This kludge tower that you describe hurts performance; you have to check
for PC being magic location and instruction being magic instruction. It
only works on some monitors, and you have to do lots of empirical testing
to see how far you can take it without losing time. Also, by adding these
fixed interval waits, you change the system performance characteristics.
This isn't to denigrate the impressive effort you've put into this, but at
some point you need to recognize that this is the wrong course.
If, as you claim, you intend a "true emulation", then changing the
performance characteristics of the processor by adding fixed interval
waits is not the way to do it. Nor is adding magic tests.
KLH10's idle stalls until the next interrupt, not a fixed interval. Once
the OS decides to enter the idle task, only some interrupt-driven event is
going to get it to exit the idle task. Thus, it is alright to stall until
the next interrupt. With a fixed interval, the stall is either too short
and doesn't buy back enough performance, or it's too long and events are
delayed (or in the case of clock events missed).
KLH10's idle instruction is a single CONO (generally to device 700), and
in both TOPS-10 and TOPS-20 it is a one-instruction patch. In TOPS-10,
replace the SOJG 6,1 at NULCOD+1 with CONO 700,1. In TOPS-20, replace the
JRST SCDNL2 at SCDNL1-1 with CONO 700,1.
Doing something like that abolishes the need for magic tests and per-OS
hacks in the emulator. The cost of patching a single instruction in the
monitor is IMHO much lower than the cost to performance.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Mark Crispin
> 33%, as one would expect, and TOPS-20 keeps accurate time.
KLH10's idle technique gives much better CPU usage reduction. My
production KLH10 system has accumulated 1752 CPU minutes in 2743 real-time
hours of TOPS-20 uptime. That's under 2%.
Johnny Eriksson
> For TOPS-10 and ITS, I've done the following:
>
> 1) The clock service runs at 60Hz and delivers a clock interrupt at
> that rate. (Yeah, if you gen'd a 50Hz T10 system, you're out of luck
> for now). I've verified that TOPS-10, at least, still keeps accurate
> time this way.
>
> 2) If ITS is running, and the simulator sees an AOJA 0,17 instruction
> in location 17 in user mode, it attempts to go idle. This is the
> standard ITS idle loop.
>
> 3) If TOPS10 is running, and the simulator sees a SOJG 6,1 instruction
> in location 1 in user mode, it attempts to go idle. This is the
> standard TOPS10 idle loop. I've verified that if TOPS-10 is idle,
> this reduces CPU usage to < 5%.
>
> Still thinking about TOPS-20. Idling could cause clock ticks to
> appear to be only a handful of instructions apart. That's fine for
> the 'fast path' through the clock interrupt handler but may not work
> if the clock handler invokes the scheduler, and another clock tick
> occurs immediately after that.
>
> /Bob
You might want to look at the (tops-10) idle code I wrote for simh
version 2.9 some years ago. Found at:
ftp://ftp.stacken.kth.se/pub/pdp10/v29upd/
Idle cpu usage for the host is around 3% on a 533MHz PC.
This also contains support for the kmc/dup combo, enabling anf-10 or
decnet over simulated sync lines.
--Johnny