Hi,
How does QNX update its software clock (date and time)? What is the
resolution of update?
thanks in advance,
Krupa
Krupa <krupah@hotmail.com> wrote:
Hi,
How does QNX update its software clock (date and time)? What is the
resolution of update?
On every timer interrupt, the OS moves the software date and time forward
by the time interval. The default value for this is normally stated as
10ms, but due to hardware issues, it ends up being just under 10ms –
about 9.999315 ms actually. This can be modified or displayed with the
ticksize utility or from code using clock_setres()/clock_getres().
-David
QNX Training Services
dagibbs@qnx.com
Hi David,
First of all I would like to thank you for answering the query posted by
me. I understand from your reply that with every timer tick the kernel will
increase the system time by 1 tick (10millisec) by default. I have tried to
go though the information documented in Watcom ‘C’ Library Reference
regarding clock_setres()/clock_getres().
From the info put together, my understanding about the time update of QNX
RTOS is as follows :
1.] timer interrupt will be triggerred every 10mSec by default
2.] the rate at which timer interrupt gets triggerred can be configured
with the help of ticksize utility
3.] On every timer tick system time by default is updated by 10mSec.
With that in mind, further questions are as follows :
1.] Are the timer interrupts accurate?
2.] If I set the ticksize to a very small value, will my system
performance get affected?
3.] How can I synchronize timer interrupts for multiple computers? This
query is mainly because if the computers running QNX are started at
different instants, the time at which timer interrupt gets triggerred will
not be the same even though the rate of interrupt generation will be same.
4.] All the computers for which I would want to synchronize the QNX
software clock will be communicating with a GPS receiver unit on a serial
port (1GPS receiver connected serial port of each computer). Based on date
and time information received from GPS receiver each QNX-computer will set
its own RTC and update QNX clock. Our worry is that if the timer interrupts
which update the software clock are not synchronised for all the computers,
the time difference of upto 10msec can be noticed. How to solve this
problem?
5.] What is the source of triggeres for timer interrupt?
I request you to help me with the QNX clock synchronisation
issues…
Regards,
Krupa
(Situ Electro Instruments Pvt.Ltd, INDIA)
David Gibbs <dagibbs@qnx.com> wrote in message
news:9g34qd$l5c$3@nntp.qnx.com…
Krupa <> krupah@hotmail.com> > wrote:
Hi,How does QNX update its software clock (date and time)? What is the
resolution of update?On every timer interrupt, the OS moves the software date and time forward
by the time interval. The default value for this is normally stated as
10ms, but due to hardware issues, it ends up being just under 10ms –
about 9.999315 ms actually. This can be modified or displayed with the
ticksize utility or from code using clock_setres()/clock_getres().-David
QNX Training Services
dagibbs@qnx.com
Krupa <krupah@hotmail.com> wrote:
Hi David,
First of all I would like to thank you for answering the query posted by
me.
Quite welcome.
I understand from your reply that with every timer tick the kernel will
increase the system time by 1 tick (10millisec) by default. I have tried to
go though the information documented in Watcom ‘C’ Library Reference
regarding clock_setres()/clock_getres().
From the info put together, my understanding about the time update of QNX
RTOS is as follows :1.] timer interrupt will be triggerred every 10mSec by default
Just under 10 mSec, but close enough.
2.] the rate at which timer interrupt gets triggerred can be configured
with the help of ticksize utility
Yes, or the clock_setres() function above.
3.] On every timer tick system time by default is updated by 10mSec.
Just under 10 mSec, but close enough.
With that in mind, further questions are as follows :
1.] Are the timer interrupts accurate?
No. They can vary from the real world time for a variety of reasons –
the crystal may not be quite on the right frequency, temperature changes
can vary the rate, and it is possible to miss interrupt 0 if an interrupt
handler for a higher priority interrupt handler is running for longer than
a full tick.
2.] If I set the ticksize to a very small value, will my system
performance get affected?
Yes. If you, for instance, drop the ticksize to 1ms, you have increased
your rate of interrupt 0 occuring 10-fold, that is you’ll get that interrupt
happening ten times as often (which directly affects system load), as well
you have all the work that would be done at that interrupt – checking the
timer chain for example – also occurring 10 times as frequently.
Depending on your hardware, and how much spare CPU you have, this may be
reasonable. Also, how much do you need a smaller ticksize? In most cases,
dropping it to 1ms is fine, but below that I’d probably want to be running
on at least a P2 class machine. (Of course, this is all relative to how
much other work you’re trying to do as well. A 486 that is just handling
the timer interrupt could keep up far better than a P3 that is 100% loaded.)
3.] How can I synchronize timer interrupts for multiple computers? This
query is mainly because if the computers running QNX are started at
different instants, the time at which timer interrupt gets triggerred will
not be the same even though the rate of interrupt generation will be same.
You can’t synchronise timer interrupts between different computers.
(Well, I don’t know of anyway – I can’t think of anyway without using
some funky hardware that plugs an I/O card into all the machines and
generates an interrupt at the same time on all the machines. That still
wouldn’t be interrupt 0 – but with appropriate work, you could probably
fake it out to be interrupt 0.)
4.] All the computers for which I would want to synchronize the QNX
software clock will be communicating with a GPS receiver unit on a serial
port (1GPS receiver connected serial port of each computer). Based on date
and time information received from GPS receiver each QNX-computer will set
its own RTC and update QNX clock. Our worry is that if the timer interrupts
which update the software clock are not synchronised for all the computers,
the time difference of upto 10msec can be noticed. How to solve this
problem?
A time difference of up to 10msec could, as you say, be noticed. First
question – how wide a discrepancy between the computers can you stand?
Or, to put it another way, what is your tolerance for accuracy?
Also, you will have to regularly re-synchronise QNX with the GPS time source.
You will want to use the function qnx_adj_time() for this – it allows
you to make your clock run a little faster/slower to re-synchronise with
an outside time source. You might take a look at
ftp.qnx.com:/usr/free/qnx4/tcpip/utils/qnx-ntp.tgz for a daemon that
maintains a syncrhonised time accross a network under QNX4 – but using
GPS, you’re probably best off just coding something up yourself. It
should periodically (how often depends on how much slippage from “real
world” time you are getting) get the system time & get the time from the
GPS & then compare them and see if it is gaining/losing and call
qnx_adj_time() to catch up / fall back.
5.] What is the source of triggeres for timer interrupt?
It is the 82C54 chip on the motherboard, triggering interrupt 0.
Please don’t program the interrupt 0 triggering directly on the
82C54, and if you want to use one of the other timers on the chip,
be VERY careful that you don’t disturb the behaviour of interrupt 0.
(The 82C54 has 3 timers, one is used for system time on irq0, one is
used for sounds from the PC speaker, the third is unused. But, the
bits to control different interrupts are intermingled in the same
registers.)
I request you to help me with the QNX clock synchronisation
issues…
I hope the above helps.
-David
QNX Training Services
dagibbs@qnx.com
Hello David,
Yes, your reply has really been of help to me.
As I had mentioned in my previos message, I am working on a time
synchronization solution using QNX based computer. The description of the
project is as follows :
A computer (embedded system) running QNX communicates with GPS Receiver
unit connected on a serial port. The communication program obtains date and
time information from the GPS receiver unit. When date-time information is
available from GPS receiver unit, the RTC of the PC is updated. For updating
RTC date and time, I have downloaded the source code from QUICS. Based on
date and time information, QNX clock is also set by my application. The date
and time of RTC and QNX clock is refreshed every one minute. All of this
appears to be working fine. We have even checked up the propagation delays
in time info transfer from GPS receiver unit to the computer. That delay
remains constant and hence may be used for fixed time offset at the
receiving end(PC).
There are other program modules running on the embedded system. These
modules need to use QNX date and time information for time stamping of a few
occurrences monitored by them. These programs will access QNX clock through
standard Watcom ‘C’ functions.
Now having worked this out, we realized that QNX clock is updated every
10 mSec. If the timer interrupt gets triggerred immediately after having
refreshed QNX clock based on time reference of GPS, the QNX clock will be
offset by 10mSec directly from the time info sent by GPS. How can I ensure
that the timer interrupt triggeres exactly 10mSec after the QNX clock
refresh ? This difference of upto 10mSec is not acceptable to the end user!
Another issue is of multiple computers synchronised using GPS receiver
units. If the time at which timer interrupts is not synchronized for all of
them, a difference of time in milliseconds will appear.You have already
mentioned that according to you it is not possible synchronize the timer
interrupts for multiple computers.
Regards,
Krupa
David Gibbs <dagibbs@qnx.com> wrote in message
news:9gamqt$e3u$1@nntp.qnx.com…
Krupa <> krupah@hotmail.com> > wrote:
Hi David,First of all I would like to thank you for answering the query
posted by
me.Quite welcome.
I understand from your reply that with every timer tick the kernel will
increase the system time by 1 tick (10millisec) by default. I have tried
to
go though the information documented in Watcom ‘C’ Library Reference
regarding clock_setres()/clock_getres().
From the info put together, my understanding about the time update of
QNX
RTOS is as follows :1.] timer interrupt will be triggerred every 10mSec by default
Just under 10 mSec, but close enough.
2.] the rate at which timer interrupt gets triggerred can be
configured
with the help of ticksize utilityYes, or the clock_setres() function above.
3.] On every timer tick system time by default is updated by 10mSec.Just under 10 mSec, but close enough.
With that in mind, further questions are as follows :1.] Are the timer interrupts accurate?
No. They can vary from the real world time for a variety of reasons –
the crystal may not be quite on the right frequency, temperature changes
can vary the rate, and it is possible to miss interrupt 0 if an interrupt
handler for a higher priority interrupt handler is running for longer than
a full tick.2.] If I set the ticksize to a very small value, will my system
performance get affected?Yes. If you, for instance, drop the ticksize to 1ms, you have increased
your rate of interrupt 0 occuring 10-fold, that is you’ll get that
interrupt
happening ten times as often (which directly affects system load), as well
you have all the work that would be done at that interrupt – checking the
timer chain for example – also occurring 10 times as frequently.Depending on your hardware, and how much spare CPU you have, this may be
reasonable. Also, how much do you need a smaller ticksize? In most
cases,
dropping it to 1ms is fine, but below that I’d probably want to be running
on at least a P2 class machine. (Of course, this is all relative to how
much other work you’re trying to do as well. A 486 that is just handling
the timer interrupt could keep up far better than a P3 that is 100%
loaded.)3.] How can I synchronize timer interrupts for multiple computers?
This
query is mainly because if the computers running QNX are started at
different instants, the time at which timer interrupt gets triggerred
will
not be the same even though the rate of interrupt generation will be
same.You can’t synchronise timer interrupts between different computers.
(Well, I don’t know of anyway – I can’t think of anyway without using
some funky hardware that plugs an I/O card into all the machines and
generates an interrupt at the same time on all the machines. That still
wouldn’t be interrupt 0 – but with appropriate work, you could probably
fake it out to be interrupt 0.)4.] All the computers for which I would want to synchronize the QNX
software clock will be communicating with a GPS receiver unit on a
serial
port (1GPS receiver connected serial port of each computer). Based on
date
and time information received from GPS receiver each QNX-computer will
set
its own RTC and update QNX clock. Our worry is that if the timer
interrupts
which update the software clock are not synchronised for all the
computers,
the time difference of upto 10msec can be noticed. How to solve this
problem?A time difference of up to 10msec could, as you say, be noticed. First
question – how wide a discrepancy between the computers can you stand?
Or, to put it another way, what is your tolerance for accuracy?Also, you will have to regularly re-synchronise QNX with the GPS time
source.
You will want to use the function qnx_adj_time() for this – it allows
you to make your clock run a little faster/slower to re-synchronise with
an outside time source. You might take a look at
ftp.qnx.com:/usr/free/qnx4/tcpip/utils/qnx-ntp.tgz for a daemon that
maintains a syncrhonised time accross a network under QNX4 – but using
GPS, you’re probably best off just coding something up yourself. It
should periodically (how often depends on how much slippage from “real
world” time you are getting) get the system time & get the time from the
GPS & then compare them and see if it is gaining/losing and call
qnx_adj_time() to catch up / fall back.5.] What is the source of triggeres for timer interrupt?
It is the 82C54 chip on the motherboard, triggering interrupt 0.
Please don’t program the interrupt 0 triggering directly on the
82C54, and if you want to use one of the other timers on the chip,
be VERY careful that you don’t disturb the behaviour of interrupt 0.
(The 82C54 has 3 timers, one is used for system time on irq0, one is
used for sounds from the PC speaker, the third is unused. But, the
bits to control different interrupts are intermingled in the same
registers.)I request you to help me with the QNX clock synchronisation
issues…I hope the above helps.
-David
QNX Training Services
dagibbs@qnx.com
Krupa <krupah@hotmail.com> wrote:
Hello David,
As I had mentioned in my previos message, I am working on a time
synchronization solution using QNX based computer. The description of the
project is as follows :Now having worked this out, we realized that QNX clock is updated every
10 mSec. If the timer interrupt gets triggerred immediately after having
refreshed QNX clock based on time reference of GPS, the QNX clock will be
offset by 10mSec directly from the time info sent by GPS. How can I ensure
that the timer interrupt triggeres exactly 10mSec after the QNX clock
refresh ? This difference of upto 10mSec is not acceptable to the end user!
Attach an interrupt handler to interrupt 0. Count instances of interrupt
0, whenever it is time to do your update, return a (high priority) proxy
to your (high priority) time update task. It will then run right after
the OS’s update of the time – so the OS won’t update the time for another
10 msec.
Another issue is of multiple computers synchronised using GPS receiver
units. If the time at which timer interrupts is not synchronized for all of
them, a difference of time in milliseconds will appear.You have already
mentioned that according to you it is not possible synchronize the timer
interrupts for multiple computers.
If you take your ticksize down, you reduce the maximum possible size of this
error, but as noted, I don’t see a way to eliminate it.
Hm… if you are running on a Pentium or better, the Pentium has a
free-running 64-bit counter on the chip that counts independently of
the timer chip or anything QNX does. Again, it won’t be synchronised
between machines – but in combination with your “current time” you
might be able to use this to get a very accurate time stamp – you’d
have to snapshot the free running counter every time you updated the
time, and then when you wanted to timestamp something, grab it again,
and do some math to get a more accurate than 10ms resolution for your
time stamps. You’d also want to benchmark on each machine how fast
the timer counts. Take a look at:
ftp.qnx.com:/usr/free/qnx4/os/utils/examples/Micro_time.tgz
for sample code for getting the counter. (At least I think that
archive has such sample code.)
Or, depending on how expensive it is to get the time from the GPS
receiver, you could just time stamp all your events that need to
be compared accross machines with a time from the GPS, rather than
worrying about keeping the system time synchronised.
Might not be solutions – but might be other possible approaches
to think about.
-David
QNX Training Services
dagibbs@qnx.com
Krupa <krupah@hotmail.com> wrote:
Hello David,
A computer (embedded system) running QNX communicates with GPS Receiver
unit connected on a serial port. The communication program obtains date and
time information from the GPS receiver unit. When date-time information is
available from GPS receiver unit, the RTC of the PC is updated. For updating
RTC date and time, I have downloaded the source code from QUICS. Based on
date and time information, QNX clock is also set by my application. The date
and time of RTC and QNX clock is refreshed every one minute.
By the way, refreshing the date & QNX clock every minute – especially if
you are running with a 10ms ticksize – is overkill. Of course, if you
have CPU power to burn, this is ok – but looking at possible slippage
rates, I’d be surprised if you found any significant change in time values
over that minute. With a 10ms resolution, slippage of less than 5 ms is
essentially unimportant.
You might be better off spending the CPU time to run with a 1ms
ticksize, but only update the time every 10 minutes or so.
-David
QNX Training Services
dagibbs@qnx.com
if you want to see an example of the rdtsc usage, please look at:
staff.qnx.com/~randy/drops/qnx4/net.test/
there are many other references on the qdn as well.
i use the code above to measure thruput and message transfer times for
various message sizes across a qnx network…
David Gibbs <dagibbs@qnx.com> wrote:
Krupa <> krupah@hotmail.com> > wrote:
Hello David,As I had mentioned in my previos message, I am working on a time
synchronization solution using QNX based computer. The description of the
project is as follows :Now having worked this out, we realized that QNX clock is updated every
10 mSec. If the timer interrupt gets triggerred immediately after having
refreshed QNX clock based on time reference of GPS, the QNX clock will be
offset by 10mSec directly from the time info sent by GPS. How can I ensure
that the timer interrupt triggeres exactly 10mSec after the QNX clock
refresh ? This difference of upto 10mSec is not acceptable to the end user!Attach an interrupt handler to interrupt 0. Count instances of interrupt
0, whenever it is time to do your update, return a (high priority) proxy
to your (high priority) time update task. It will then run right after
the OS’s update of the time – so the OS won’t update the time for another
10 msec.Another issue is of multiple computers synchronised using GPS receiver
units. If the time at which timer interrupts is not synchronized for all of
them, a difference of time in milliseconds will appear.You have already
mentioned that according to you it is not possible synchronize the timer
interrupts for multiple computers.If you take your ticksize down, you reduce the maximum possible size of this
error, but as noted, I don’t see a way to eliminate it.Hm… if you are running on a Pentium or better, the Pentium has a
free-running 64-bit counter on the chip that counts independently of
the timer chip or anything QNX does. Again, it won’t be synchronised
between machines – but in combination with your “current time” you
might be able to use this to get a very accurate time stamp – you’d
have to snapshot the free running counter every time you updated the
time, and then when you wanted to timestamp something, grab it again,
and do some math to get a more accurate than 10ms resolution for your
time stamps. You’d also want to benchmark on each machine how fast
the timer counts. Take a look at:
ftp.qnx.com:/usr/free/qnx4/os/utils/examples/Micro_time.tgz
for sample code for getting the counter. (At least I think that
archive has such sample code.)Or, depending on how expensive it is to get the time from the GPS
receiver, you could just time stamp all your events that need to
be compared accross machines with a time from the GPS, rather than
worrying about keeping the system time synchronised.Might not be solutions – but might be other possible approaches
to think about.-David
QNX Training Services
dagibbs@qnx.com
–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579