# timer in QNX 6.1

In the article of "tick-tock-understanding the Neutrino micro kernel’s
concept’, it is mentioned that there is a 153 nanosecond(ns) disecrepancy
between the request and what the hardware can do, and then to request a
timer event of .999847 ms instead of 1ms will get the precise timing. I’m
wondering if I adjust the ticksize to smaller or bigger, there still exists
153ns discrepancy between the request and what the hardware can do, or this
value is changed with different ticksize?

Thanks,

Belinda

Belinda,

For understanding this inaccuracy, it is important to understand how hardware work:
The frequency from quartz oscillator (1.19318 MHz) is divided by 8254 timer to INTEGER divisor.
I.E.

1193.18 kHz / 1193 = 1.000150880134 kHz, not exactly 1.0 kHz, so you have period 0.999849 ms

Let’s suppose you want the 300 us ticksize, then system will set

1193.18 kHz / 357 = 3.342241 kHz
and ticksize = 299.200456 us
i.e. inaccuracy is ~800ns

or system will set
1193.18 kHz / 358 = 3.33291 kHz
and ticksize = 300.038552 us
i.e. inaccuracy is ~38.5ns

But I believe (don’t remember where I get this knowledge from) system will set
smallest ticksize (299.2 us) and inaccuracy will big enough.

## HTH. Cheers,

Eduard.
ed1k at ukr dot net

Belinda <yye@is2.dal.ca> wrote in article <aeoob5\$1e2\$1@inn.qnx.com>…

In the article of "tick-tock-understanding the Neutrino micro kernel’s
concept’, it is mentioned that there is a 153 nanosecond(ns) disecrepancy
between the request and what the hardware can do, and then to request a
timer event of .999847 ms instead of 1ms will get the precise timing. I’m
wondering if I adjust the ticksize to smaller or bigger, there still exists
153ns discrepancy between the request and what the hardware can do, or this
value is changed with different ticksize?

Thanks,

Belinda

ed1k <ed1k@spamerstrap.com> wrote:

Belinda,

And, of course, if you’re not in the land of the x86, the
fundamental frequency of your quartz oscillator will probably
be different as well…

-David

For understanding this inaccuracy, it is important to understand how hardware work:
The frequency from quartz oscillator (1.19318 MHz) is divided by 8254 timer to INTEGER divisor.
I.E.

1193.18 kHz / 1193 = 1.000150880134 kHz, not exactly 1.0 kHz, so you have period 0.999849 ms

Let’s suppose you want the 300 us ticksize, then system will set

1193.18 kHz / 357 = 3.342241 kHz
and ticksize = 299.200456 us
i.e. inaccuracy is ~800ns

or system will set
1193.18 kHz / 358 = 3.33291 kHz
and ticksize = 300.038552 us
i.e. inaccuracy is ~38.5ns

But I believe (don’t remember where I get this knowledge from) system will set
smallest ticksize (299.2 us) and inaccuracy will big enough.

## HTH. Cheers,

Eduard.
ed1k at ukr dot net

Belinda <> yye@is2.dal.ca> > wrote in article <aeoob5\$1e2\$> 1@inn.qnx.com> >…
In the article of "tick-tock-understanding the Neutrino micro kernel’s
concept’, it is mentioned that there is a 153 nanosecond(ns) disecrepancy
between the request and what the hardware can do, and then to request a
timer event of .999847 ms instead of 1ms will get the precise timing. I’m
wondering if I adjust the ticksize to smaller or bigger, there still exists
153ns discrepancy between the request and what the hardware can do, or this
value is changed with different ticksize?

Thanks,

Belinda
\

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> wrote in article <af7sop\$iad\$5@nntp.qnx.com>…

ed1k <> ed1k@spamerstrap.com> > wrote:
Belinda,

And, of course, if you’re not in the land of the x86, the
fundamental frequency of your quartz oscillator will probably
be different as well…

## Ah, I only tried to explain the principles, not exactly values of freqs. Actually, in accordance with Robert Krten’s book (russian language edition), the frequency is 1.1931816 MHz in x86. Have no time and desires to connect the frequency meter and measure it Anyway, everyone could call ClockPeriod() twice, firstly to set ticksize and secondly to read actually setted ticksize. BTW, What is long fract (reserved) in _clockperiod structure for? Definitelly such small time quantity is nonsense for quartz oscillator (it’s smaller than noise of quartz oscillator), is it waited for next generation of much more precission and cheap oscillators ;-P?

Eduard.
ed1k at ukr dot net

-David

For understanding this inaccuracy, it is important to understand how hardware work:
The frequency from quartz oscillator (1.19318 MHz) is divided by 8254 timer to INTEGER divisor.
I.E.

1193.18 kHz / 1193 = 1.000150880134 kHz, not exactly 1.0 kHz, so you have period 0.999849 ms

Let’s suppose you want the 300 us ticksize, then system will set

1193.18 kHz / 357 = 3.342241 kHz
and ticksize = 299.200456 us
i.e. inaccuracy is ~800ns

or system will set
1193.18 kHz / 358 = 3.33291 kHz
and ticksize = 300.038552 us
i.e. inaccuracy is ~38.5ns

But I believe (don’t remember where I get this knowledge from) system will set
smallest ticksize (299.2 us) and inaccuracy will big enough.

## HTH. Cheers,

Eduard.
ed1k at ukr dot net

Belinda <> yye@is2.dal.ca> > wrote in article <aeoob5\$1e2\$> 1@inn.qnx.com> >…
In the article of "tick-tock-understanding the Neutrino micro kernel’s
concept’, it is mentioned that there is a 153 nanosecond(ns) disecrepancy
between the request and what the hardware can do, and then to request a
timer event of .999847 ms instead of 1ms will get the precise timing. I’m
wondering if I adjust the ticksize to smaller or bigger, there still exists
153ns discrepancy between the request and what the hardware can do, or this
value is changed with different ticksize?

Thanks,

## Belinda \

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

i cann’t make sense what it is said in the below. How does the system know
to choose 357 or 357 as integer divisor. And I want to make sure whether the
smallest value of ticksize in QNX 6.01 is 500us.

Additionally, if I set a timer, and the interval time doens’t equal to
ticksize, such as a bigger value than ticksize, how does it impose upon the
system?

Thanks,

Belinda

Let’s suppose you want the 300 us ticksize, then system will set

1193.18 kHz / 357 = 3.342241 kHz
and ticksize = 299.200456 us
i.e. inaccuracy is ~800ns

or system will set
1193.18 kHz / 358 = 3.33291 kHz
and ticksize = 300.038552 us
i.e. inaccuracy is ~38.5ns

“ed1k” <ed1k@spamerstrap.com> Ð´ÈëÏûÏ¢ÐÂÎÅ
:01c21cea\$8638f580\$106fa8c0@ED1K…

David Gibbs <> dagibbs@qnx.com> > wrote in article
ed1k <> ed1k@spamerstrap.com> > wrote:
Belinda,

And, of course, if you’re not in the land of the x86, the
fundamental frequency of your quartz oscillator will probably
be different as well…

## Ah, I only tried to explain the principles, not exactly values of freqs. Actually, in accordance with Robert Krten’s book (russian language edition), the frequency is 1.1931816 MHz in x86. Have no time and desires to connect the frequency meter and measure it > > Anyway, everyone could call ClockPeriod() twice, firstly to set ticksize and secondly to read actually setted ticksize. BTW, What is long fract (reserved) in _clockperiod structure for? Definitelly such small time quantity is nonsense for quartz oscillator (it’s smaller than noise of quartz oscillator), is it waited for next generation of much more precission and cheap oscillators ;-P?

Eduard.
ed1k at ukr dot net

-David

For understanding this inaccuracy, it is important to understand how
hardware work:
The frequency from quartz oscillator (1.19318 MHz) is divided by 8254
timer to INTEGER divisor.
I.E.

1193.18 kHz / 1193 = 1.000150880134 kHz, not exactly 1.0 kHz, so you
have period 0.999849 msLet’s suppose you want the 300 us ticksize, then

system will set

1193.18 kHz / 357 = 3.342241 kHz
and ticksize = 299.200456 us
i.e. inaccuracy is ~800ns

or system will set
1193.18 kHz / 358 = 3.33291 kHz
and ticksize = 300.038552 us
i.e. inaccuracy is ~38.5ns

But I believe (don’t remember where I get this knowledge from) system
will set
smallest ticksize (299.2 us) and inaccuracy will big enough.

## HTH. Cheers,

Eduard.
ed1k at ukr dot net

Belinda <> yye@is2.dal.ca> > wrote in article
aeoob5\$1e2\$> 1@inn.qnx.com> >…
In the article of "tick-tock-understanding the Neutrino micro
kernel’s
concept’, it is mentioned that there is a 153 nanosecond(ns)
disecrepancy
between the request and what the hardware can do, and then to request
a
timer event of .999847 ms instead of 1ms will get the precise timing.
I’m
wondering if I adjust the ticksize to smaller or bigger, there still
exists
153ns discrepancy between the request and what the hardware can do,
or this
value is changed with different ticksize?

Thanks,

## Belinda \

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Belinda <yye@is2.dal.ca> wrote in article <afja4c\$74p\$1@inn.qnx.com>…

i cann’t make sense what it is said in the below. How does the system know
to choose 357 or 357 as integer divisor.

The kernel knows the frequency of oscillator in your system. It’s 1.1931816 MHz on all x86
platforms. You have to don’t care about frequencies and divisors. By kernel’s call (ClockPeriod)
you tell to the kernel “I want 300 us timeslice” (by appropriate field in _clockperiod structure
newtime). The kernel calculates that divisor and sees the divisor 357 is good, because when divisor
is 358 you’ll have the timeslice worse than 300 us. Then kernel sets hardware (puts divisor into
8254 hwrd timer) to have interrupt every 299.200456 us. You can read this value by call
ClockPeriod once more with NULL as newtime and empty structure oldtime, see actual timeslice in
nanosec in this oldtime structure.

And I want to make sure whether the
smallest value of ticksize in QNX 6.01 is 500us.

If you will try to setup 300 us or 499 us by ClockPeriod it will not take effect. The smallest
value in QNX 6.0 - 6.1A is 500 us, just try to setup smallest value to be sure.

Additionally, if I set a timer, and the interval time doens’t equal to
ticksize, such as a bigger value than ticksize, how does it impose upon the
system?

The timer and timeslice are different. The timeslice is the time precission of system. This is a
time unit for timers. It’s a smallest quantity of time for kernel. For instanse, the timeslice is
300 us and you set the timer for 1.3 sec. The kernel will creat internal variable for your timer
with the value
1300000 / 299.200456 = 4345. You see, the kernel knows and uses the actual timeslice. Kernel will
decrement this value every timer interrupt, and when the variable reaches 0, the kernel will
generate the event for your timer. So, you’ll get the timer’s event not early than the time of
timer (1.3 sec in example). It’s important, you can’t get time precission of timers better than
timeslice, and timer gets you the time more or equal to the required time in accordance with the
POSIX (read as “always more because there is timeslice in a system”).
If you will try to setup the timer for 300 us and in ideal system (there are not threads with
bigest priorities) you’ll get timer’s event during next 300-600 us. Setting the timer and hardware
time interrupts are asyncronously processes, so if you set the timer exactly after timer interrupt
you will get the worse precission: the time which you setted plus the mainly all time of timeslice
(it’s “dead” time for the kernel, kernel will wait for the next timer interrupt and from this first
timemark will calculate time for your timer). Don’t think “kernel will wait” - in reality it just
rounds the timer variable to biggest value ) (300 / 299.200456 = 2) Or, may be, just add 1, I
guess kernel guys should know.

I highly suggest you to buy Robert’s book. You’ll find many answers for your questions. Also there
are few good developers articles about time at qnx web site.

## Cheers,

Eduard.
ed1k at ukr dot net

Thanks,

Belinda

ed1k <ed1k@spamerstrap.com> wrote in article 01c220f7\$10b67880\$106fa8c0@ED1K

there
are few good developers articles about time at qnx web site.

## Belinda, lucky for you there is “Clocks, Timers and Getting a Kick Every So Often” chapter from Robert Krten’s book at his company web site, free for reading:)http://www.parse.com/books/book_v3/sample.html Enjoy,

Eduard.
ed1k at ukr dot net

ed1k <ed1k@spamerstrap.com> wrote in article 01c21cea\$8638f580\$106fa8c0@ED1K

David Gibbs <> dagibbs@qnx.com> > wrote in article <af7sop\$iad\$> 5@nntp.qnx.com> >…
ed1k <> ed1k@spamerstrap.com> > wrote:

Ah, I only tried to explain the principles, not exactly values of freqs. Actually, in accordance
with Robert Krten’s book (russian language edition), the frequency is 1.1931816 MHz in x86. Have
no
time and desires to connect the frequency meter and measure it >

## Actually in my Pentium system it’s 14.31818 MHz… exactly in 12 times faster… Cheers,

Eduard.
ed1k at ukr dot net