Realtime clock and system timer
Ciaran Keating
Nothing very important here, but I was just wondering...
I don't understand why they clocks are named like they are. The "realtime
clock" counts ticks and not time, at a frequency that varies by machine,
whereas the "system timer" is a real clock with a fixed, known frequency
that can be calibrated to give timings in hours, minutes and seconds.
Have I got it backwards, or is there some explanation that I'm missing, or
is it indeed just one of those things?
--
Ciaran Keating
Amadan Technologies
Alexei A. Frounze
RTC is a separate chip or part of the chip set. It keeps the wall
clock time and date and should be pretty accurate at that. The
periodic interrupt that you can get from it should also be accurate
(on average in the long term) and have good resolution. Other timers
have other purposes. The ACPI PM timer is supposed to be very accurate
but its resolution is low and its access times are known to be pretty
slow and it doesn't generate any interrupts. The regular programmable
interval timer is simple and good for simple things, it has good
resolution but it doesn't have to be very accurate. The APIC timer has
good resolution, but its not very accurate: the rate is derived from
the bus clock rate and the timer can stop in deep C states. The TSC
has perhaps the best resolution, but it doesn't generate any
interrupts and it too has accuracy issues and can stop in low power
states. Furthermore, TSCs in MP systems generally don't count at the
same rate. Can be close, but not the same. There're some high
performance/multimedia timer but I don't know of those anything,
except they probably should be very accurate, with high resolution,
low access times, etc. I don't know if they are subject to stopping in
low power modes.
So, depending on your needs the system timer (as in OS timer) can be
anything that's suitable. It can be even a synthetic time source made
out of several others.
Alex
Alexei A. Frounze
...
> So, depending on your needs the system timer (as in OS timer) can be
> anything that's suitable. It can be even a synthetic time source made
> out of several others.
>
> Alex
Oh, and it depends on what exactly one means by "real time": high rate/
resolution or high accuracy, that is, real/true time.
Alex
Wolfgang Kern
Ciaran Keating wrote:
> Hi all,
> Nothing very important here, but I was just wondering...
> I don't understand why they clocks are named like they are. The "realtime
> clock" counts ticks and not time, at a frequency that varies by machine,
> whereas the "system timer" is a real clock with a fixed, known frequency
> that can be calibrated to give timings in hours, minutes and seconds.
> Have I got it backwards, or is there some explanation that I'm missing, or
:) My RTCL got an Xtal and counts quite exact Seconds/.../Years.
but because old I/O-based clock-chips where awful slow to read,
IBM, M$-DOS and others may have once decided to just read time/date on
startup and then either just let the IRQ-8 count Seconds, or usually
abuse the IRQ-0 timer with 18.2Hz for further time counting, so saving
on several slow I/O-reads in the IRQ-routines and update the system-
timer-variables 'manually' (ended up in some calculation needs...).
Haven't checked if windoze or L'unix follow this method.
> is it indeed just one of those things?
:) looks like an anchient relict of discrete I/O-chips vs. CPU-speed.
My personal approach is to read three I/O-ports (hh:mm:ss) on IRQ-8
and just set 'Second updated' and 'Date-changed' bits which are then
used in the Wait/Idle-Loop to re-draw/-print the clock as neccessary
and (if any) invoke long termed tasks on date/time matches.
So I have my IRQ0-timer free for other things like 1mS-based timeout
counters, time-sliced job queus and delays.
And as I synchronise one IRQ0-counter by the RTCL-IRQ, I got 1 mSec
granulated time-stamps for file date/time and other in addition.
__
wolfgang
Maxim S. Shatskih
> abuse the IRQ-0 timer with 18.2Hz for further time counting, so saving
> on several slow I/O-reads in the IRQ-routines and update the system-
> timer-variables 'manually' (ended up in some calculation needs...).
> Haven't checked if windoze or L'unix follow this method.
Same, but a) RTC can be used as interrupt source instead of PIT b) Windows
sometimes synchronizes the RTC internal date/time with its own.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Ciaran Keating
> :) My RTCL got an Xtal and counts quite exact Seconds/.../Years.
>
> but because old I/O-based clock-chips where awful slow to read,
> IBM, M$-DOS and others may have once decided to just read time/date on
> startup and then either just let the IRQ-8 count Seconds, or usually
> abuse the IRQ-0 timer with 18.2Hz for further time counting, so saving
> on several slow I/O-reads in the IRQ-routines and update the system-
> timer-variables 'manually' (ended up in some calculation needs...).
> Haven't checked if windoze or L'unix follow this method.
Ah, I see. That might explain how the terminology started to get mixed up.
And then perhaps I compounded my own confusion because I couldn't get the
IRQ8 clock to do my bidding. My code comments aren't exactly helpful: "The
APIC realtime clock doesn't seem to want to play, so use the Pentium
timestamp counter instead" - pity I didn't note exactly what the problem
was!
As far as I can make out, the APIC "system timer" at IRQ0 is also called
PIT. It runs at a fixed 1.19318MHz - that's what I call real time, because
its timing is known and reliable and can be related to wall clock time.
The APIC "real time clock" at IRQ8 seems to run at whatever the local bus
speed is (or something like that) and so it's not real time at all... as
far as I can make out.
> My personal approach is to read three I/O-ports (hh:mm:ss) on IRQ-8
> and just set 'Second updated' and 'Date-changed' bits which are then
> used in the Wait/Idle-Loop to re-draw/-print the clock as neccessary
> and (if any) invoke long termed tasks on date/time matches.
Are these the CMOS time ports?
> So I have my IRQ0-timer free for other things like 1mS-based timeout
> counters, time-sliced job queus and delays.
> And as I synchronise one IRQ0-counter by the RTCL-IRQ, I got 1 mSec
> granulated time-stamps for file date/time and other in addition.
So far, in my baby OS where nothing's very important yet, I've configured
the PIT to interrupt at 100kHz and on each interrupt I increment a
counter. Then I calibrate the TSC to find out how many times it ticks in
one second - this gives me a very high resolution timer suitable for very
short busy hardware waits. I also use the CMOS time to know the current
date and time at a human level.
Ciaran Keating
<alexf...@gmail.com> wrote:
> RTC is a separate chip or part of the chip set. It keeps the wall
> clock time and date and should be pretty accurate at that. The
> periodic interrupt that you can get from it should also be accurate
> (on average in the long term) and have good resolution.
What exactly is this clock? I'm guessing it's not the CMOS clock because
that doesn't generate interrupts. I'm guessing it's not the APIC IRQ8 you
mention an "APIC timer" below.
> The APIC timer has
> good resolution, but its not very accurate: the rate is derived from
> the bus clock rate and the timer can stop in deep C states.
Ah, maybe that's what I've been thinking of as the "real time clock". This
is IRQ8 on the APIC, right?
> So, depending on your needs the system timer (as in OS timer) can be
> anything that's suitable.
Well, my needs are modest :-) I think I've implemented what I need, but I
just wanted to clear up some confusion in my head. This is what I've got:
CMOS to tell me the current date and time. Responds to explicit requests.
IRQ0 to give me regular 100kHz interrupts. I think I can base my task
scheduling and sleeps on this.
TSC to measure very short intervals. I use this for hardware busy waits,
like waiting for DMA to settle down or the disk to spin, or whatever.
Maxim S. Shatskih
> like waiting for DMA to settle down or the disk to spin, or whatever.
The disk spins for too long to use busy wait for it.
Wolfgang Kern
Ciaran Keating wrote:
>> :) My RTCL got an Xtal and counts quite exact Seconds/.../Years.
>> but because old I/O-based clock-chips where awful slow to read,
>> IBM, M$-DOS and others may have once decided to just read time/date on
>> startup and then either just let the IRQ-8 count Seconds, or usually
>> abuse the IRQ-0 timer with 18.2Hz for further time counting, so saving
>> on several slow I/O-reads in the IRQ-routines and update the system-
>> timer-variables 'manually' (ended up in some calculation needs...).
>> Haven't checked if windoze or L'unix follow this method.
> Ah, I see. That might explain how the terminology started to get mixed up.
> And then perhaps I compounded my own confusion because I couldn't get the
> IRQ8 clock to do my bidding. My code comments aren't exactly helpful: "The
> APIC realtime clock doesn't seem to want to play, so use the Pentium
> timestamp counter instead" - pity I didn't note exactly what the problem
> was!
> As far as I can make out, the APIC "system timer" at IRQ0 is also called
> PIT. It runs at a fixed 1.19318MHz - that's what I call real time, because
The PIT can be programmed because it got a clock divider in addition.
its standard settings are 0xFFFF which gives us the 'famous ~18.2 Hz'.
> its timing is known and reliable and can be related to wall clock time.
> The APIC "real time clock" at IRQ8 seems to run at whatever the local bus
> speed is (or something like that) and so it's not real time at all... as
> far as I can make out.
APIC-timer and RTCL are different things and shouldn't share IRQ08.
The RTCL should be a clock-chip like the one on your wrist.
Or was it about the often seen port 0x70/71 issue ?
The IRQ08 comes out of the CMOS-RAM-Clock-chip on my machine(s).
this interrupt can be programmed to: 1/1024 Sec or (standard) 1 Sec
in addition to an 24h alarm interrupt(IRQ08 too) and also can run
in single shot mode, in opposition to periodic interrupts.
>> My personal approach is to read three I/O-ports (hh:mm:ss) on IRQ-8
>> and just set 'Second updated' and 'Date-changed' bits which are then
>> used in the Wait/Idle-Loop to re-draw/-print the clock as neccessary
>> and (if any) invoke long termed tasks on date/time matches.
> Are these the CMOS time ports?
Exact. I configured (standard anyway) my CMOS-Clock to 1 Sec/periodic.
>> So I have my IRQ0-timer free for other things like 1mS-based timeout
>> counters, time-sliced job queus and delays.
>> And as I synchronise one IRQ0-counter by the RTCL-IRQ, I got 1 mSec
>> granulated time-stamps for file date/time and other in addition.
> So far, in my baby OS where nothing's very important yet, I've configured
> the PIT to interrupt at 100kHz and on each interrupt I increment a
> counter. Then I calibrate the TSC to find out how many times it ticks in
> one second - this gives me a very high resolution timer suitable for very
> short busy hardware waits. I also use the CMOS time to know the current
> date and time at a human level.
Yeah, I do something similar to detect the actual CPU-frequency and I
added a few count-down-until-zero counters to the IRQ0-routine to ease
HW-timout-handling by load a time value and check for Zero.
100 KHz ??? or it's just close enough with 100.0067052 KHz :)
My "millSecond" is also just near with divider at 0x4aa (999.31323),
but you got hundred times more, so you should be aware of the duration
of your IRQ-routines, especially if you plan to add event-driven stuff.
__
wolfgang
Ciaran Keating
> APIC-timer and RTCL are different things and shouldn't share IRQ08.
> The RTCL should be a clock-chip like the one on your wrist.
So is this the IRQ8 timer?
> Or was it about the often seen port 0x70/71 issue ?
Sorry, I don't understand this bit...?
> The IRQ08 comes out of the CMOS-RAM-Clock-chip on my machine(s).
> this interrupt can be programmed to: 1/1024 Sec or (standard) 1 Sec
> in addition to an 24h alarm interrupt(IRQ08 too) and also can run
> in single shot mode, in opposition to periodic interrupts.
I might have another go at IRQ8. Next time I'm bored!
> 100 KHz ???
Oops! 100Hz.
> or it's just close enough with 100.0067052 KHz :)
Yeah, it's just close enough.
Ciaran Keating
<ma...@storagecraft.com> wrote:
>> TSC to measure very short intervals. I use this for hardware busy waits,
>> like waiting for DMA to settle down or the disk to spin, or whatever.
>
> The disk spins for too long to use busy wait for it.
Well, I'm not really all that bothered about that right now. I just want
to get the OS working well enough for me to learn the fundamentals, and to
feel that I've done it. I'll probably never care about high performance or
ultra-smooth task switching :-)
Wolfgang Kern
Ciaran Keating wrote:
>> APIC-timer and RTCL are different things and shouldn't share IRQ08.
>> The RTCL should be a clock-chip like the one on your wrist.
> So is this the IRQ8 timer?
Yes, the RTCL-Interrupt is 'wired' to IRQ8 an all my machines.
APIC and PCI-config may be able to change this, but I never saw it.
>> Or was it about the often seen port 0x70/71 issue ?
> Sorry, I don't understand this bit...?
RBIL: "... any write to port 0x70 must be followed by either a
write or read port 0x71" ;
(it may stop,tristate,reset,...?? otherwise)
>> The IRQ08 comes out of the CMOS-RAM-Clock-chip on my machine(s).
>> this interrupt can be programmed to: 1/1024 Sec or (standard) 1 Sec
>> in addition to an 24h alarm interrupt(IRQ08 too) and also can run
>> in single shot mode, in opposition to periodic interrupts.
> I might have another go at IRQ8. Next time I'm bored!
:) RBIL (ports-list) is still a recommendable source for this.
>> 100 KHz ???
> Oops! 100Hz.
100 KHz timer would be possible on ~2GHz CPUs without much problems.
>> or it's just close enough with 100.0067052 KHz :)
> Yeah, it's just close enough.
IIRC the only exact timing figure on the PIT is 20Hz (50mS)
with a divider of 0xE90B (59659). Looks like this base frequency
were once chosen to not interfiere with 50Hz nor much with 60Hz
nor with TV/Radio-internal frequency ranges, or was it just
because IBM once had too many wrong ordered X-tals on stock ? :).
__
wolfgang
Matt
thought that this would give a short enough period for good smooth
interpolation of tasks, without a huge percentage of the time being
taken in task switching.
Matt
Wolfgang Kern
Matt mentioned:
...
> I have the PIT set to 3287, which gives exactly 363 counts per second. I
> thought that this would give a short enough period for good smooth
> interpolation of tasks, without a huge percentage of the time being
> taken in task switching.
Fine, if your chosen time-base of 363 Hz will fit all you demands.
I once searched for a 'real-time compatible' value and ended up with
(almost close) 0x04AA for ~1mS, even the last (.999 Seconds) will be
synchronised by the RTCL and show a slightly different duration <1mS.
sure, all dividable values are exact achievable, but most values
are hard to synchronize with the RTCL (as part of actual true time).
__
wolfgang
James Harris
...
> I have the PIT set to 3287, which gives exactly 363 counts per second. I
> thought that this would give a short enough period for good smooth
> interpolation of tasks, without a huge percentage of the time being
> taken in task switching.
Surely the clock divider should depend on the speed of the machine,
no? To keep the percentage of time taken by task switching low and
fairly uniform an older slower machine may need fewer task switches
per second whereas a newer faster machine may be able to handle many
more in the same time. Put another way, any fixed number of task
changes per second may be a lot if the code happens to be running on
an old box, IMHO.
Ciaran Keating
>>> Or was it about the often seen port 0x70/71 issue ?
>
>> Sorry, I don't understand this bit...?
>
> RBIL: "... any write to port 0x70 must be followed by either a
> write or read port 0x71" ;
> (it may stop,tristate,reset,...?? otherwise)
Hmm... I don't think that was my problem. I do explicitly read the CMOS
clock via ports 0x70/71. To read port 0x71 after writing port 0x70 makes
sense - why else would anyone write to 0x70, if not to subsequently read
or write 0x71?
>>> The IRQ08 comes out of the CMOS-RAM-Clock-chip on my machine(s).
>>> this interrupt can be programmed to: 1/1024 Sec or (standard) 1 Sec
>>> in addition to an 24h alarm interrupt(IRQ08 too) and also can run
>>> in single shot mode, in opposition to periodic interrupts.
Ah, so the same CMOS clock (which works fine for me) is the source of
IRQ8? Now that's something I didn't know.
>> I might have another go at IRQ8. Next time I'm bored!
>
> :) RBIL (ports-list) is still a recommendable source for this.
Indeed. Thanks for the reminder.
Rod Pemberton
news:g2lfia$t4g$2...@newsreader2.utanet.at...
> IIRC the only exact timing figure on the PIT is 20Hz (50mS)
> with a divider of 0xE90B (59659). Looks like this base frequency
> were once chosen to not interfiere with 50Hz nor much with 60Hz
> nor with TV/Radio-internal frequency ranges, or was it just
> because IBM once had too many wrong ordered X-tals on stock ? :).
>
I think these calculations are correct:
(You may need to track down the original NTSC standard if you need to know
for sure...)
4.5Mhz US TV bandwidth/channel
15750Hz US BW (black and white) TV horizontal sync
60Hz US BW TV vertical sync
572 total lines/frame including vertical sync
horizontal/vertical ratio = 525/2 = 15750Hz/60Hz
3.579545Mhz US colorburst frequency
3.58Mhz = 4.5Mhz*(455/572)
(odd multiple of bandwidth 455 chosen for colorburst to prevent
herring-bone interference)
15734.26Hz color TV horizontal sync
15734Hz = 3.58Mhz/(455/2)
(the two is for interlacing)
59.94Hz color TV vertical sync
59.94Hz = 15734Hz/(525/2)
(the two is for interlacing)
horizontal/vertical ratio (preserved) = 525/2 = 15734Hz/59.94Hz
14.318181Mhz common TV crystal
14.318Mhz = 4*3.58Mhz
(cheap TV crystal - not sure what used for in TV's - perhaps ring
oscillator...)
1.193Mhz PC PIT clock
1.193181.8Mhz = 14.318Mhz/12
18.20Hz PC IRQ0 clock
18.2065Hz (54.9255ms) = 1.93182Mhz/65536
HTH,
Rod Pemberton
Rod Pemberton
news:op.ucj08bxnlndgv1@beaker...
> sense - why else would anyone write to 0x70, if not to subsequently read
> or write 0x71?
If you don't need to use the value that could be read, why read? See...
coding error... the chip requires it. I actually did this at first.
Rod Pemberton
Ciaran Keating
<do_no...@nohavenot.cmm> wrote:
> "Ciaran Keating" <cia...@amadantech.com> wrote in message
> news:op.ucj08bxnlndgv1@beaker...
>> To read port 0x71 after writing port 0x70 makes
>> sense - why else would anyone write to 0x70, if not to subsequently read
>> or write 0x71?
>
> If you don't need to use the value that could be read, why read? See...
> coding error... the chip requires it. I actually did this at first.
I meant: why would you write to port 0x70 if you didn't intend to follow
it up with a read or write to 0x71? Isn't the point of writing to 0x70
just to indicate which data byte you want to read or write?
Wolfgang Kern
Ciaran Keating wrote:
>>>> Or was it about the often seen port 0x70/71 issue ?
>...- why else would anyone write to 0x70, if not to subsequently read
> or write 0x71?
ie: the classical bug on 'disable NMI': OUT 0x70,0x80
without a dummy IN 71h.
>>>> The IRQ08 comes out of the CMOS-RAM-Clock-chip on my machine(s).
...
> Ah, so the same CMOS clock (which works fine for me) is the source of
> IRQ8? Now that's something I didn't know.
seems to be standard since PC-AT joined in ...
__
wolfgang
Wolfgang Kern
Rod Pemberton replied in detail:
>> [about PIT frequency] ... or was it just
>> because IBM once had too many wrong ordered X-tals on stock ? :).
> I think these calculations are correct:
...
> 14.318181Mhz common TV crystal
> 14.318Mhz = 4*3.58Mhz
> (cheap TV crystal
That may be exact the main cause: "cheap mass production item".
> - not sure what used for in TV's - perhaps ring oscillator...)
I think they used a multiple color burst frequency to gain precision
and to reduce thermal effects with an also cheap divide by four.
Many years ago I used to work as a TV-technician, but I'm more
familiar with the European PAL, so I know very little about NTSC.
> HTH,
yes, thanks Rod
__
wolfgang
Wolfgang Kern
James Harris mentioned:
> ...
I'm not sure if this idea will perform as you think ...
Assume an old game or any animated picture or a whole movie,
wouldn't it run in slow motion on an older PCs and Fast Forward
on new ones ? :)
I think 1mS should be 1mS independent of CPU and Bus-speed.
But right, a faster machine can to more things within a given
time-slice. An OS may know the environment frequencies and
hardware latencies, so it can decide to allow more 'parallel'
actions on faster machines.
__
wolfgang
Ciaran Keating
>
> Ciaran Keating wrote:
>
>>>>> Or was it about the often seen port 0x70/71 issue ?
>> ...- why else would anyone write to 0x70, if not to subsequently read
>> or write 0x71?
>
> ie: the classical bug on 'disable NMI': OUT 0x70,0x80
> without a dummy IN 71h.
Ah yes, of course. Now I see Rod's point. I suppose the chip designers
either failed to imagine this problem, or figured that it was too complex
or too expensive to avoid and so was just something their users would have
to learn.