System time inaccuracy

How does system time gets maintained once it has been read from
hardware? We are observing rougly 15 min per day deviation between
hardware clock and OS time on x86 platform. Is it normal? I suppose we
could do “rtc hw” every so often, but it does not sound right to me so I
thought you might want to know…

  • Igor

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

How does system time gets maintained once it has been read from
hardware? We are observing rougly 15 min per day deviation between
hardware clock and OS time on x86 platform. Is it normal? I suppose we
could do “rtc hw” every so often, but it does not sound right to me so I
thought you might want to know…

That doesn’t sound right at all. I keep my RTP development machine
on 25/7 with a reboot happening only when the driver I am testing on
it spins inside an interrupt handler. :wink: I don’t see any deviation.
Anyone else?

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Just some Ideas:


really off crystal / PLL / divider tick size (got a frequency counter) ?

Which one is more correct to the (corrected - NTP, WWV/CHU) wall clock ?

SMM mode


Chris McKillop <cdm@qnx.com> wrote in message
news:9fq2n2$5iu$1@nntp.qnx.com

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:

How does system time gets maintained once it has been read from
hardware? We are observing rougly 15 min per day deviation between
hardware clock and OS time on x86 platform. Is it normal? I suppose we
could do “rtc hw” every so often, but it does not sound right to me so I
thought you might want to know…


That doesn’t sound right at all. I keep my RTP development machine
on 25/7 with a reboot happening only when the driver I am testing on
it spins inside an interrupt handler. > :wink: > I don’t see any deviation.
Anyone else?

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

Hardware clock is correct and it matches what we see on Sun. But NTO OS
time appears to lag behind, so after 24 hours it is 14 min behind Sun.
If we reboot system OS time ‘catches up’.

  • igor

“Michael J. Ferrador” wrote:

Just some Ideas:

really off crystal / PLL / divider tick size (got a frequency counter) ?

Which one is more correct to the (corrected - NTP, WWV/CHU) wall clock ?

SMM mode

Chris McKillop <> cdm@qnx.com> > wrote in message
news:9fq2n2$5iu$> 1@nntp.qnx.com> …
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:

How does system time gets maintained once it has been read from
hardware? We are observing rougly 15 min per day deviation between
hardware clock and OS time on x86 platform. Is it normal? I suppose we
could do “rtc hw” every so often, but it does not sound right to me so I
thought you might want to know…


That doesn’t sound right at all. I keep my RTP development machine
on 25/7 with a reboot happening only when the driver I am testing on
it spins inside an interrupt handler. > :wink: > I don’t see any deviation.
Anyone else?

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

Every tick the kernel adds the ticksize to the current time that
it keeps in memory. This is done in an interrupt handler, int 0
on x86. Do you have a higher priority interrupt that takes a long
time in its handler? If the higher prio one runs for 3 ticks, for
example, then the int 0 handler would get called only when that higher
prio one finishes but it would add only 1 tick to the current time.
If this is just a desktop then you may not have noticed but if there
are time critical things running, you’d probably have noticed this
already.

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

How does system time gets maintained once it has been read from
hardware? We are observing rougly 15 min per day deviation between
hardware clock and OS time on x86 platform. Is it normal? I suppose we
could do “rtc hw” every so often, but it does not sound right to me so I
thought you might want to know…

  • Igor

And what would be interrupt with priority higher than int0? I thought it
is highest… Does NTO re-program interrupt controller to change
priorities or how else it is possible?

  • igor

Steven Dufresne wrote:

Every tick the kernel adds the ticksize to the current time that
it keeps in memory. This is done in an interrupt handler, int 0
on x86. Do you have a higher priority interrupt that takes a long
time in its handler? If the higher prio one runs for 3 ticks, for
example, then the int 0 handler would get called only when that higher
prio one finishes but it would add only 1 tick to the current time.
If this is just a desktop then you may not have noticed but if there
are time critical things running, you’d probably have noticed this
already.

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
How does system time gets maintained once it has been read from
hardware? We are observing rougly 15 min per day deviation between
hardware clock and OS time on x86 platform. Is it normal? I suppose we
could do “rtc hw” every so often, but it does not sound right to me so I
thought you might want to know…

  • Igor

Don’t know about RTP but in QNX4, hardware interrupt priorities are rotated by
default so that 3 is highest, then 4, etc. and around to zero.

Igor Kovalenko wrote:

And what would be interrupt with priority higher than int0? I thought it
is highest… Does NTO re-program interrupt controller to change
priorities or how else it is possible?

  • igor

Steven Dufresne wrote:

Every tick the kernel adds the ticksize to the current time that
it keeps in memory. This is done in an interrupt handler, int 0
on x86. Do you have a higher priority interrupt that takes a long
time in its handler? If the higher prio one runs for 3 ticks, for
example, then the int 0 handler would get called only when that higher
prio one finishes but it would add only 1 tick to the current time.
If this is just a desktop then you may not have noticed but if there
are time critical things running, you’d probably have noticed this
already.

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
How does system time gets maintained once it has been read from
hardware? We are observing rougly 15 min per day deviation between
hardware clock and OS time on x86 platform. Is it normal? I suppose we
could do “rtc hw” every so often, but it does not sound right to me so I
thought you might want to know…

  • Igor

Can someone confirm or deny this (wrt RTP)? If that is the case, why
this is necessary and what would be a way to fix problem?

Thanks,

  • igor

Dean Douthat wrote:

Don’t know about RTP but in QNX4, hardware interrupt priorities are rotated by
default so that 3 is highest, then 4, etc. and around to zero.

Igor Kovalenko wrote:

And what would be interrupt with priority higher than int0? I thought it
is highest… Does NTO re-program interrupt controller to change
priorities or how else it is possible?

  • igor

Steven Dufresne wrote:

Every tick the kernel adds the ticksize to the current time that
it keeps in memory. This is done in an interrupt handler, int 0
on x86. Do you have a higher priority interrupt that takes a long
time in its handler? If the higher prio one runs for 3 ticks, for
example, then the int 0 handler would get called only when that higher
prio one finishes but it would add only 1 tick to the current time.
If this is just a desktop then you may not have noticed but if there
are time critical things running, you’d probably have noticed this
already.

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
How does system time gets maintained once it has been read from
hardware? We are observing rougly 15 min per day deviation between
hardware clock and OS time on x86 platform. Is it normal? I suppose we
could do “rtc hw” every so often, but it does not sound right to me so I
thought you might want to know…

  • Igor

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

Can someone confirm or deny this (wrt RTP)? If that is the case, why
this is necessary and what would be a way to fix problem?

The most likely cause is an out of whack crystal driving the timer interrupt.
Once the RTC hardware has been consulted by startup to determine the boot
up time, the system just maintains time of day by counting the interrupts
and calulation based on the

timer_rate, timer_scale, timer_load

fields of the qtime entry of the system page (unless of course the
rtc command is run, at which point we reset based on the RTC hardware again).
The first two fields are set by startup, the last calculated by the first
two and the system tick interval requested by ClockPeriod() (usually 1ms).
If the crystal driving the timer interrupt is running at a significantly
different frequency than what timer_rate & timer_scale say, you’ll get the
symptom you’re seeing.

On IBM PC’s startup sets the fields as follows:

#define PC_CLOCK_RATE 838095345UL /* period in femtoseconds /
qtime->timer_rate = PC_CLOCK_RATE;
qtime->timer_scale = -15; /
timer_rate is in femtoseconds */

Unfortunately, there’s currently no way to get startup-bios to put in
different values for those two fields.


Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

There is also IRQTUNE for Linux

http://www.best.com/~cae/irqtune/

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote in message
news:3B2102B5.C4DAE406@motorola.com

And what would be interrupt with priority higher than int0? I thought it
is highest… Does NTO re-program interrupt controller to change
priorities or how else it is possible?

  • igor

Steven Dufresne wrote:

Every tick the kernel adds the ticksize to the current time that
it keeps in memory. This is done in an interrupt handler, int 0
on x86. Do you have a higher priority interrupt that takes a long
time in its handler? If the higher prio one runs for 3 ticks, for
example, then the int 0 handler would get called only when that higher
prio one finishes but it would add only 1 tick to the current time.
If this is just a desktop then you may not have noticed but if there
are time critical things running, you’d probably have noticed this
already.

We have seen this on some non intel x86 motherboards using QNX 4.24 and 4.25

We eventually just read the cmos time directly every hour

Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.os:

Hardware clock is correct and it matches what we see on Sun. But NTO OS
time appears to lag behind, so after 24 hours it is 14 min behind Sun.
If we reboot system OS time ‘catches up’.

  • igor

“Michael J. Ferrador” wrote:

Just some Ideas:

really off crystal / PLL / divider tick size (got a frequency counter) ?

Which one is more correct to the (corrected - NTP, WWV/CHU) wall clock ?

SMM mode

Chris McKillop <> cdm@qnx.com> > wrote in message
news:9fq2n2$5iu$> 1@nntp.qnx.com> …
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:

How does system time gets maintained once it has been read from
hardware? We are observing rougly 15 min per day deviation between
hardware clock and OS time on x86 platform. Is it normal? I suppose we
could do “rtc hw” every so often, but it does not sound right to me so I
thought you might want to know…


That doesn’t sound right at all. I keep my RTP development machine
on 25/7 with a reboot happening only when the driver I am testing on
it spins inside an interrupt handler. > :wink: > I don’t see any deviation.
Anyone else?

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

Actually, I would think that IRQ0 would be the sixth highest priority
(on an x86). At least it was (by default) on QNX4, and it makes the
most sense given the architecture of the 8259. Making IRQ3 the highest
priority interrupt means that the interrupt priority order is
(descending from highest prio to lowest):

3
4
5
6
7
0
1
2 → second controller
| 8
±-----9
10
11
12
13
14
15

-----Original Message-----
From: Igor Kovalenko [mailto:Igor.Kovalenko@motorola.com]
Posted At: Friday, June 08, 2001 9:52 AM
Posted To: os
Conversation: System time inaccuracy
Subject: Re: System time inaccuracy


And what would be interrupt with priority higher than int0? I thought it
is highest… Does NTO re-program interrupt controller to change
priorities or how else it is possible?