Hello,
has anyone ever experienced the system clock to run slower or faster than
normal on a QNX 4.25? We have at least one machine (uname -a: QNX 12 L 425
PCI 32) where one wall clock second seems to be approx. 0.5 clock() seconds,
so all measurements are 2x slower than real time? Our application is using
timers. Rebooting seems to have helped… is this something I should expect
on a regular basis? Is it possible that this could be caused by some sort of
bug in our code (we do not set the system time from our app, just read it)?
Thanks in advance,
Ida
–
Ida Zokalj, dipl.ing.rac.
ida.zokalj@telefon-gradnja.hr
[www.telefon-gradnja.hr]
tel. +385 (1) 3388 534
Telefon-Gradnja d.o.o.
Plesivicka 3, 10431 Sveta Nedjelja, Croatia
tel. +385 (1) 3388 500
fax. +385 (1) 3388 599
The problem is most likely the computer hardware itself - clocks do vary.
I recently logged clock adjustments over a 4 hour period to two identical
computers being synchronized to GPS time. One computer lost slightly over 1
second while the other gained 2.5 seconds in the 4 hour period.
If timing is critical in your application, you may have to find an external
time source to sync to or a high precision clock to install in your
computer.
Gord
“Ida ®okalj” <ida.zokalj@telefon-gradnja.hr> wrote in message
news:cgd0r6$lhm$1@inn.qnx.com…
Hello,
has anyone ever experienced the system clock to run slower or faster than
normal on a QNX 4.25? We have at least one machine (uname -a: QNX 12 L 425
PCI 32) where one wall clock second seems to be approx. 0.5 clock()
seconds,
so all measurements are 2x slower than real time? Our application is using
timers. Rebooting seems to have helped… is this something I should
expect
on a regular basis? Is it possible that this could be caused by some sort
of
bug in our code (we do not set the system time from our app, just read
it)?
Thanks in advance,
Ida
–
Ida Zokalj, dipl.ing.rac.
ida.zokalj@telefon-gradnja.hr
[> www.telefon-gradnja.hr> ]
tel. +385 (1) 3388 534
Telefon-Gradnja d.o.o.
Plesivicka 3, 10431 Sveta Nedjelja, Croatia
tel. +385 (1) 3388 500
fax. +385 (1) 3388 599
Thanks for the reply, but I don’t think that’s it. Maybe I didn’t
explain it well enough. It’s not like we are getting a slight offset
from wall clock time - time goes twice as slow! For example:
Fishy QNX machine <==> Wall clock (say it is precise enough)
11:28:01 <==> 15:03:35
11:28:06 <==> 15:03:45
11:28:11 <==> 15:03:55
etc.
The weird bit is that after the reboot everything was fine! If it
weren’t, we’d suspect the hardware, but currently the machine
is working fine.
Ida
“Gord Sipko” <mountkidd@shaw.ca> wrote in message
news:cge0r9$eug$1@inn.qnx.com…
The problem is most likely the computer hardware itself - clocks do vary.
I recently logged clock adjustments over a 4 hour period to two identical
computers being synchronized to GPS time. One computer lost slightly over
1
second while the other gained 2.5 seconds in the 4 hour period.
If timing is critical in your application, you may have to find an
external
time source to sync to or a high precision clock to install in your
computer.
Gord
“Ida okalj” <ida.zokalj@telefon-gradnja.hr> wrote:
Io > Thanks for the reply, but I don’t think that’s it. Maybe I didn’t
Io > explain it well enough. It’s not like we are getting a slight offset
Io > from wall clock time - time goes twice as slow! For example:
Io > Fishy QNX machine <==> Wall clock (say it is precise enough)
Io > 11:28:01 <==> 15:03:35
Io > 11:28:06 <==> 15:03:45
Io > 11:28:11 <==> 15:03:55
Io > etc.
Io > The weird bit is that after the reboot everything was fine! If it
Io > weren’t, we’d suspect the hardware, but currently the machine
Io > is working fine.
Io > Ida
My guess, and that’s all it is is a guess, is that something is
disableing interrupts for way too long.
So your clock is interrupting close to the correct rate but the timer
interrupt isn’t being serviced until the next timer tick.
Do you have any drivers that you wrote yourself?
Are you hanging a lot of things on a timer interrupt?
Hi, I apologize for the long time it took me to reply.
My guess, and that’s all it is a guess, is that something is
disabling interrupts for way too long.
So your clock is interrupting close to the correct rate but the timer
interrupt isn’t being serviced until the next timer tick.
Sounds like a good explanation to me.
Do you have any drivers that you wrote yourself?
Note: Being relatively new to the company I myself didn’t take part
in creation of the application. I deal mostly with bug fixes and
enhancements on non-important bits.
No we don’t load any custom drivers.
Are you hanging a lot of things on a timer interrupt?
I guess so. I checked how many of them application is using on machine
that went haywire. A lot - 62.
Most timers are used on communication lines that use up to 5
timers by instance and that machine has the largest number
of communications lines to date - 7 (+ 1 control).
The application itself is run on dozen other places for months/years
and there wasn’t any similar behaviour but then it is usually
run with 4 communications lines.
Thanks for your response, we are still trying to find what happend and
to reproduce the problem.
Ida
“Ida okalj” <ida.zokalj@telefon-gradnja.hr> wrote:
Are you hanging a lot of things on a timer interrupt?
Io > I guess so. I checked how many of them application is using on machine
Io > that went haywire. A lot - 62.
Io > Most timers are used on communication lines that use up to 5
Io > timers by instance and that machine has the largest number
Io > of communications lines to date - 7 (+ 1 control).
Io > The application itself is run on dozen other places for months/years
Io > and there wasn’t any similar behaviour but then it is usually
Io > run with 4 communications lines.
Io > Thanks for your response, we are still trying to find what happend and
Io > to reproduce the problem.
Let me ask again, are these all being hung on THE timer interrupt,
i.e. interrupt #0, or are you creating seperate timers for each of the
timers that you need?
I don’t think your trying to do too much, I’m guessing that your
checking too many things too often when you don’t need to.
Try to only generate an interrupt when you know there is something to
check.