Timer resolution

Hi

Has anyone managed to speed up the clock-period to faster than
2000Hz with a call to ClockPeriod (CLOCK_REALTIME…)
and made it work.

Is there an OS-limitation due to overhead in kernel-sheduling or
hardware-timer?

/Gunnar

<gunnar.bostrom@optonova.se> wrote:

Has anyone managed to speed up the clock-period to faster than
2000Hz with a call to ClockPeriod (CLOCK_REALTIME…)
and made it work.

Is there an OS-limitation due to overhead in kernel-sheduling or
hardware-timer?

There’s a lower limit of 500 microseconds for the clock because we
wanted to be able to detect & error when people accidently fed spurious
values to ClockPeriod(). The actual number is somewhat arbitrary. Can
you tell us why you want a faster clock tick?


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

“Brian Stecher” <bstecher@qnx.com> wrote in message
news:8v0rju$et4$1@nntp.qnx.com

gunnar.bostrom@optonova.se> > wrote:
Has anyone managed to speed up the clock-period to faster than
2000Hz with a call to ClockPeriod (CLOCK_REALTIME…)
and made it work.

Is there an OS-limitation due to overhead in kernel-sheduling or
hardware-timer?

There’s a lower limit of 500 microseconds for the clock because we
wanted to be able to detect & error when people accidently fed spurious
values to ClockPeriod(). The actual number is somewhat arbitrary. Can
you tell us why you want a faster clock tick?

Here’s a vote for 100 usec. The reason I may need this is for a software
oscilliscope for instance, where I want a high sampling rate for monitoring
(say) a servo control loop. Without 100 usec resolution it may be necessary
to have a external hardware interrupt for monitoring frequencies that are
within a reasonable mechanical time domain. I think 100 usec (10Khz for
sampling 5Khz signals) is sufficient for just about all mechanical time
constants one might encounter in common practice. Seems a shame to have to
have an external interrupt when 100 usec should be easily doable in this day
and age (1Ghz processors and whatnot)…

The goal here is to have a pulse frequency, that has sufficient bandwidth
for most things mechanical (not suggesting radar signal processing here :slight_smile:

“John Doe” <john@csical.com> wrote in message
news:8v1d8h$iv5$1@inn.qnx.com

“Brian Stecher” <> bstecher@qnx.com> > wrote in message
news:8v0rju$et4$> 1@nntp.qnx.com> …
gunnar.bostrom@optonova.se> > wrote:
Has anyone managed to speed up the clock-period to faster than
2000Hz with a call to ClockPeriod (CLOCK_REALTIME…)
and made it work.

Is there an OS-limitation due to overhead in kernel-sheduling or
hardware-timer?

There’s a lower limit of 500 microseconds for the clock because we
wanted to be able to detect & error when people accidently fed spurious
values to ClockPeriod(). The actual number is somewhat arbitrary. Can
you tell us why you want a faster clock tick?


Here’s a vote for 100 usec. The reason I may need this is for a software
oscilliscope for instance, where I want a high sampling rate for
monitoring
(say) a servo control loop. Without 100 usec resolution it may be
necessary
to have a external hardware interrupt for monitoring frequencies that are
within a reasonable mechanical time domain. I think 100 usec (10Khz for
sampling 5Khz signals) is sufficient for just about all mechanical time
constants one might encounter in common practice. Seems a shame to have
to
have an external interrupt when 100 usec should be easily doable in this
day
and age (1Ghz processors and whatnot)…

The goal here is to have a pulse frequency, that has sufficient bandwidth
for most things mechanical (not suggesting radar signal processing here
:slight_smile:

Brian,

Wouldn’t it be a good feature to have the limit CPU frequency sensitive, or
to provide an option somewhere that would tell the lower limit the
kernel should accept ( option to proc-nto???)

Mario Charest a écrit :

“John Doe” <> john@csical.com> > wrote in message
news:8v1d8h$iv5$> 1@inn.qnx.com> …

“Brian Stecher” <> bstecher@qnx.com> > wrote in message
news:8v0rju$et4$> 1@nntp.qnx.com> …
gunnar.bostrom@optonova.se> > wrote:
Has anyone managed to speed up the clock-period to faster than
2000Hz with a call to ClockPeriod (CLOCK_REALTIME…)
and made it work.

Is there an OS-limitation due to overhead in kernel-sheduling or
hardware-timer?

There’s a lower limit of 500 microseconds for the clock because we
wanted to be able to detect & error when people accidently fed spurious
values to ClockPeriod(). The actual number is somewhat arbitrary. Can
you tell us why you want a faster clock tick?


Here’s a vote for 100 usec. The reason I may need this is for a software
oscilliscope for instance, where I want a high sampling rate for
monitoring
(say) a servo control loop. Without 100 usec resolution it may be
necessary
to have a external hardware interrupt for monitoring frequencies that are
within a reasonable mechanical time domain. I think 100 usec (10Khz for
sampling 5Khz signals) is sufficient for just about all mechanical time
constants one might encounter in common practice. Seems a shame to have
to
have an external interrupt when 100 usec should be easily doable in this
day
and age (1Ghz processors and whatnot)…

The goal here is to have a pulse frequency, that has sufficient bandwidth
for most things mechanical (not suggesting radar signal processing here
:slight_smile:


Brian,

Wouldn’t it be a good feature to have the limit CPU frequency sensitive, or
to provide an option somewhere that would tell the lower limit the
kernel should accept ( option to proc-nto???)

\

Good suggestion Mario because at the rate of the processor’s speed increases, it
seems a pity to limit arbitrarly the speed of the OS.

Alain.

I need an automatic control system with a small closed loop. Now, I need to
design an
external timer-board that supplies me with the interrupts.

My needs ~4000 Hz

As other “speekers” in this matter it seems like a general need?! Could it
be a feature in the next release
perhaps?

/g

Brian Stecher <bstecher@qnx.com> wrote in message
news:8v0rju$et4$1@nntp.qnx.com

gunnar.bostrom@optonova.se> > wrote:
Has anyone managed to speed up the clock-period to faster than
2000Hz with a call to ClockPeriod (CLOCK_REALTIME…)
and made it work.

Is there an OS-limitation due to overhead in kernel-sheduling or
hardware-timer?

There’s a lower limit of 500 microseconds for the clock because we
wanted to be able to detect & error when people accidently fed spurious
values to ClockPeriod(). The actual number is somewhat arbitrary. Can
you tell us why you want a faster clock tick?


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

Mario Charest <mcharest@zinformatic.com> wrote:

Wouldn’t it be a good feature to have the limit CPU frequency sensitive, or
to provide an option somewhere that would tell the lower limit the
kernel should accept ( option to proc-nto???)

We’ve thought about that. The problem with the CPU frequency sensitive
is that we’re only estimating the speed, so the MHz rating can bounce
up and down by a bit => leading to a minimum clock period that will
bounce up and down from boot to boot. Yuck.

Call it a religious issue, but I don’t feel that the option is the
right way to go either.

We’re willing to be convinced on all the above though, so once everyone’s
had their say on this thread we’ll get together here and figure out what
we’re going to do.


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

“Brian Stecher” <bstecher@qnx.com> wrote in message
news:8v3emu$1ku$1@nntp.qnx.com

Mario Charest <> mcharest@zinformatic.com> > wrote:
Wouldn’t it be a good feature to have the limit CPU frequency sensitive,
or
to provide an option somewhere that would tell the lower limit the
kernel should accept ( option to proc-nto???)

We’ve thought about that. The problem with the CPU frequency sensitive
is that we’re only estimating the speed, so the MHz rating can bounce
up and down by a bit => leading to a minimum clock period that will
bounce up and down from boot to boot. Yuck.


Call it a religious issue, but I don’t feel that the option is the
right way to go either.

I agree to, but I couldn’t come up with any other idea ;-(

We’re willing to be convinced on all the above though, so once everyone’s
had their say on this thread we’ll get together here and figure out what
we’re going to do.

What about a new ThreadCtl flag, to turn the limit checking on/off. That
means
a program really has to go out of it’s way (so to speak) to go beyond the
“safe limit
of 500us”.


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

We’ve thought about that. The problem with the CPU frequency sensitive
is that we’re only estimating the speed, so the MHz rating can bounce
up and down by a bit => leading to a minimum clock period that will
bounce up and down from boot to boot. Yuck.

IMHO difference between processors now used is much larger than error in
speed estimation. You can set some interval for frequency to fit in
particular clock period to avoid different boot to boot values.

Brian,

Is there an efficiency issue here? How much kernel overhead is required
to maintain a 5kHz or 10kHz clock compared to having an external
hardware clock generating an interrupt? I know you probably don’t have
hard numbers, but would you guess 0.1%, 1%, 10%, or 100% cpu usage
for, let’s say, a 10khz clock on a PIII 500MHz machine? Also, does calling
ClockPeriod() change the time-slicing resolution of the scheduler (which
could
be a performance hit because probably most tasks don’t need to run at
kHz rates)?

Thanks,

-Arthur

“Gunnar Boström” <gunnar.bostrom@optonova.se> wrote in message
news:8v2loe$qpk$1@inn.qnx.com

I need an automatic control system with a small closed loop. Now, I need
to
design an
external timer-board that supplies me with the interrupts.

My needs ~4000 Hz

As other “speekers” in this matter it seems like a general need?! Could it
be a feature in the next release
perhaps?

/g

Brian Stecher <> bstecher@qnx.com> > wrote in message
news:8v0rju$et4$> 1@nntp.qnx.com> …
gunnar.bostrom@optonova.se> > wrote:
Has anyone managed to speed up the clock-period to faster than
2000Hz with a call to ClockPeriod (CLOCK_REALTIME…)
and made it work.

Is there an OS-limitation due to overhead in kernel-sheduling or
hardware-timer?

There’s a lower limit of 500 microseconds for the clock because we
wanted to be able to detect & error when people accidently fed spurious
values to ClockPeriod(). The actual number is somewhat arbitrary. Can
you tell us why you want a faster clock tick?


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

Arthur <3_arthur@my-deja.com> wrote:

Is there an efficiency issue here? How much kernel overhead is required
to maintain a 5kHz or 10kHz clock compared to having an external
hardware clock generating an interrupt?

There is some efficiency gains with using external hardware - the timer
clock also updates the time of day, checks for timeslice expiry, and
looks to see what other timers have expired. None of those need to
be done if you’re on a separate interrupt.

I know you probably don’t have
hard numbers, but would you guess 0.1%, 1%, 10%, or 100% cpu usage
for, let’s say, a 10khz clock on a PIII 500MHz machine?

I’d probably guess more in the 1% range, but it’s a complete guess.

Also, does calling
ClockPeriod() change the time-slicing resolution of the scheduler

The timeslice interval is fixed at every four clock ticks so, yes, using
ClockPeriod() does affect the resolution.

In a realtime system, it’s better to not depend on the timeslice interval
being any particular value. Use priorities to control what you want to
run - that way they’ll get the CPU just as soon as possible. Hopefully
they don’t take overly long to do their thing (less than a timeslice)
and then go back to sleep.


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

Have you designed you timer-board? If yes then have you measured the time
between each interrupt handler call? I have an external ISA-board that
generates interrupt each ms, but I see that my handler sometimes is called
after 1.066 ms. (You can read about this problem in this newsgoup in thread
with subject “interrupt latency”). This error is too big for me and in your
case (4KHz) this difference should give even bigger error. Or your system works
better than my?

Alex

“Gunnar Boström” wrote:

I need an automatic control system with a small closed loop. Now, I need to
design an
external timer-board that supplies me with the interrupts.

My needs ~4000 Hz

As other “speekers” in this matter it seems like a general need?! Could it
be a feature in the next release
perhaps?

/g

Brian Stecher <> bstecher@qnx.com> > wrote in message
news:8v0rju$et4$> 1@nntp.qnx.com> …
gunnar.bostrom@optonova.se> > wrote:
Has anyone managed to speed up the clock-period to faster than
2000Hz with a call to ClockPeriod (CLOCK_REALTIME…)
and made it work.

Is there an OS-limitation due to overhead in kernel-sheduling or
hardware-timer?

There’s a lower limit of 500 microseconds for the clock because we
wanted to be able to detect & error when people accidently fed spurious
values to ClockPeriod(). The actual number is somewhat arbitrary. Can
you tell us why you want a faster clock tick?


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