I have encountered a problem where the system tick apears to be not what is
reported by “ticksize”. When running a program which controls digital
outputs it
appears that a call to the “delay(1)” function actually takes 100ms . (I
have
also tried “nanodelay”). There are no other processes (other than those
QNX that cannot be removed) on the same, higher or lower priority,
my process is at priority 30 !
If I load the program using the WATCOM debugger and reset the ticksize in a
console to 0.5 and then run the program - everything is fine (“delay(1)” = 1
ms), if
I reset the program and do not reset the ticksize back to 0.5 ms the delay
takes 100ms
again. Ticksize will always report 0.5 ms !
Has anyone ever experienced this ? - Using QNX 4.22
Bob miles wrote:
I have encountered a problem where the system tick apears to be not what is
reported by “ticksize”. When running a program which controls digital
outputs it
appears that a call to the “delay(1)” function actually takes 100ms . (I
have
also tried “nanodelay”). There are no other processes (other than those
QNX that cannot be removed) on the same, higher or lower priority,
my process is at priority 30 !
If I load the program using the WATCOM debugger and reset the ticksize in a
console to 0.5 and then run the program - everything is fine (“delay(1)” = 1
ms), if
I reset the program and do not reset the ticksize back to 0.5 ms the delay
takes 100ms
again. Ticksize will always report 0.5 ms !
Has anyone ever experienced this ? - Using QNX 4.22
I’m using RTP and have experienced similiar. I would imagine that the
Watcom compiler puts in an intrinsic call to ClockPeriod(). The docs say
that by default this is set to 1 ms. AND that it can’t be set to lower
than 500usecs. Is there no way to make timers go faster? I was playing
with RTAI-Linux a couple weeks ago and there I could create periodic
threads (I thot it was a nicer API than the QNX posix ones) and I could
generate square waves at a much higher frequency than 500usecs. What
gives with that. I would rather be able to set it as low as possible,
let me tune the value to what my machine can handle.
–
Travis Griggs (a.k.a. Lord of the Fries)
Member: 3rd Boolean State Software Collective
Key Technology
“It had better be a pretty good meeting to be better than no meeting at
all”-- Boyd K. Packer
Travis Griggs <tgriggs@keyww.com> wrote:
I’m using RTP and have experienced similiar. I would imagine that the
Watcom compiler puts in an intrinsic call to ClockPeriod(). The docs say
that by default this is set to 1 ms. AND that it can’t be set to lower
than 500usecs. Is there no way to make timers go faster? I was playing
with RTAI-Linux a couple weeks ago and there I could create periodic
threads (I thot it was a nicer API than the QNX posix ones) and I could
generate square waves at a much higher frequency than 500usecs. What
gives with that. I would rather be able to set it as low as possible,
let me tune the value to what my machine can handle.
I would be interested in seeing how those period threads are handled.
I strongly doubt they are being schedualed but are instead “spinning”
to give you the timing you want. That is more then possible with
QNX using the nanospin() call.
chris
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
all the timers in qnx4 are based on the resolution of the current
ticksize.
delay calls nanosleep which in turn calls timer_create with a realtime
timer.
if you run ‘ticksize -e’ what does it say? as root you can set this
tickvalue to lower than .5ms if you use the -e option (nanosecs)
e.g. on my machine i use:
ticksize -e 99733
to get 100usec resolution.
be aware though that ticksize will determine how often an irq0 will fire off.
so every app that has a handler for irq0 will run every tick. plus the
kernel will run every tick and need to update internal timers etc.
note: current qnx is 425 … there are a number of enhancements and fixes
since 422 which is quite old now.
Bob miles <rmiles@radamec.co.uk> wrote:
I have encountered a problem where the system tick apears to be not what is
reported by “ticksize”. When running a program which controls digital
outputs it
appears that a call to the “delay(1)” function actually takes 100ms . (I
have
also tried “nanodelay”). There are no other processes (other than those
QNX that cannot be removed) on the same, higher or lower priority,
my process is at priority 30 !
If I load the program using the WATCOM debugger and reset the ticksize in a
console to 0.5 and then run the program - everything is fine (“delay(1)” = 1
ms), if
I reset the program and do not reset the ticksize back to 0.5 ms the delay
takes 100ms
again. Ticksize will always report 0.5 ms !
Has anyone ever experienced this ? - Using QNX 4.22
–
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
Previously, Bob miles wrote in comp.os.qnx:
Hopefully you are not running a CPU that is using supervisor mode.
An example of a CPU that can do this is the Cyrix Media GX.
With this type of processor you can see relatively large glitches
in cpu cycles, sometimes at very inconvient moments.
I have encountered a problem where the system tick apears to be not what is
reported by “ticksize”. When running a program which controls digital
outputs it
appears that a call to the “delay(1)” function actually takes 100ms . (I
have
also tried “nanodelay”). There are no other processes (other than those
QNX that cannot be removed) on the same, higher or lower priority,
my process is at priority 30 !
If I load the program using the WATCOM debugger and reset the ticksize in a
console to 0.5 and then run the program - everything is fine (“delay(1)” = 1
ms), if
I reset the program and do not reset the ticksize back to 0.5 ms the delay
takes 100ms
again. Ticksize will always report 0.5 ms !
Has anyone ever experienced this ? - Using QNX 4.22
\
–
Mitchell Schoenbrun --------- maschoen@pobox.com
Randy Martin wrote:
all the timers in qnx4 are based on the resolution of the current
ticksize.
delay calls nanosleep which in turn calls timer_create with a realtime
timer.
if you run ‘ticksize -e’ what does it say? as root you can set this
tickvalue to lower than .5ms if you use the -e option (nanosecs)
e.g. on my machine i use:
ticksize -e 99733
to get 100usec resolution.
be aware though that ticksize will determine how often an irq0 will fire off.
so every app that has a handler for irq0 will run every tick. plus the
kernel will run every tick and need to update internal timers etc.
note: current qnx is 425 … there are a number of enhancements and fixes
since 422 which is quite old now.
What if I am using 6? I think that’s what I’m allowed to download off of
their website. find / -name ticksize turns up nothing under RTP. The
above indeed sounds like what we want. We just want to get down to a
250usec period.
Travis Griggs (a.k.a. Lord of the Fries)
Member: 3rd Boolean State Software Collective
Key Technology
“It had better be a pretty good meeting to be better than no meeting at
all”-- Boyd K. Packer
Chris McKillop wrote:
Travis Griggs <> tgriggs@keyww.com> > wrote:
I’m using RTP and have experienced similiar. I would imagine that the
Watcom compiler puts in an intrinsic call to ClockPeriod(). The docs say
that by default this is set to 1 ms. AND that it can’t be set to lower
than 500usecs. Is there no way to make timers go faster? I was playing
with RTAI-Linux a couple weeks ago and there I could create periodic
threads (I thot it was a nicer API than the QNX posix ones) and I could
generate square waves at a much higher frequency than 500usecs. What
gives with that. I would rather be able to set it as low as possible,
let me tune the value to what my machine can handle.
I would be interested in seeing how those period threads are handled.
I strongly doubt they are being schedualed but are instead “spinning”
to give you the timing you want. That is more then possible with
QNX using the nanospin() call.
I assume nanospin() actually consumes resources though. I don’t know how
those period threads are being handled. But it’s open source and you can
download and divest its guts if you want
(http://www.aero.polimi.it/projects/rtai/). I spent some time playing
this afternoon. I was able to create a module which sets the timer to
5usecs and runs a periodic thread at 25usec. It did a pretty good job of
hitting that (very weak estimates of jitter about 1usec). To convince
myself that it wasn’t using some sort of nanospin(), I modified it to
run two threads at said frequency, but out of phase with each other. And
all the while I could run Konquerer comfortably in the background.
Maybe, I could use the RTAI source to figure out what low level calls
set the clock multiplier, and then just use that to set it lower than
QNX6 wants to let me.
–
Travis Griggs (a.k.a. Lord of the Fries)
Member: 3rd Boolean State Software Collective
Key Technology
“It had better be a pretty good meeting to be better than no meeting at
all”-- Boyd K. Packer
Travis Griggs <tgriggs@keyww.com> wrote:
Maybe, I could use the RTAI source to figure out what low level calls
set the clock multiplier, and then just use that to set it lower than
QNX6 wants to let me. <grin
Ahhh, they are doing the same trick BeOS does then. 
The timer you
have been looking at with neutrino is the main OS/system timer-tick.
Which is a fixed interval timer that drives the OS. However, another
approach is to have a varying interval timer which you re-program based
on shortest timeout. I am not a huge PC internals expert but I think there
are two different timers that can be setup, one that drives the OS and
one that can be used in this timeout manner. I have no clue as to the
support of such a thing on QNX6. If they are infact different timers
it shouldn’t be too hard to add support to QNX - but if they are the same
it will be very hard.
chris
\
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Chris McKillop wrote:
Travis Griggs <> tgriggs@keyww.com> > wrote:
Maybe, I could use the RTAI source to figure out what low level calls
set the clock multiplier, and then just use that to set it lower than
QNX6 wants to let me. <grin
Ahhh, they are doing the same trick BeOS does then. > > The timer you
have been looking at with neutrino is the main OS/system timer-tick.
Which is a fixed interval timer that drives the OS. However, another
approach is to have a varying interval timer which you re-program based
on shortest timeout. I am not a huge PC internals expert but I think there
are two different timers that can be setup, one that drives the OS and
one that can be used in this timeout manner. I have no clue as to the
support of such a thing on QNX6. If they are infact different timers
it shouldn’t be too hard to add support to QNX - but if they are the same
it will be very hard.
So… back to what I really want to do. How do I get an action to occur
every 250usec using QNX6 without consuming all resources? Is it possible?
Travis Griggs (a.k.a. Lord of the Fries)
Member: 3rd Boolean State Software Collective
Key Technology
“It had better be a pretty good meeting to be better than no meeting at
all”-- Boyd K. Packer
the original post was re qnx4 so that’s why i responded in that vein.
in neutrino, you use ClockPeriod to adjust your clock… but current
neutrino only lets you set it to 0.5 msecs at the lowest.
my understanding is that this limit will be dropped in the future…
but this timer interval is still the rate that irq0 or equiv will get
fired at.
if you run on x86 you could use the other timers of the 8254… you can
seed these with a countdown value and get an irq from them. there are many
many free libs on the web that show how to do this… we had one posted
in our free software section called Microtime … it was a qnx4 program
but the part that hits the timer chip would be the same logic.
Travis Griggs <tgriggs@keyww.com> wrote:
Randy Martin wrote:
all the timers in qnx4 are based on the resolution of the current
ticksize.
delay calls nanosleep which in turn calls timer_create with a realtime
timer.
if you run ‘ticksize -e’ what does it say? as root you can set this
tickvalue to lower than .5ms if you use the -e option (nanosecs)
e.g. on my machine i use:
ticksize -e 99733
to get 100usec resolution.
be aware though that ticksize will determine how often an irq0 will fire off.
so every app that has a handler for irq0 will run every tick. plus the
kernel will run every tick and need to update internal timers etc.
note: current qnx is 425 … there are a number of enhancements and fixes
since 422 which is quite old now.
What if I am using 6? I think that’s what I’m allowed to download off of
their website. find / -name ticksize turns up nothing under RTP. The
above indeed sounds like what we want. We just want to get down to a
250usec period.
Travis Griggs (a.k.a. Lord of the Fries)
Member: 3rd Boolean State Software Collective
Key Technology
“It had better be a pretty good meeting to be better than no meeting at
all”-- Boyd K. Packer
–
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
Previously, Travis Griggs wrote in comp.os.qnx:
So… back to what I really want to do. How do I get an action to occur
every 250usec using QNX6 without consuming all resources? Is it possible?
Have you looked at the periodic interrupt hardware. This
has been around since the IBM/AT as part of the clock CMOS
chip. It can interrupt at 244.141us or even faster. I think
that it is still available on most PC hardware. It attaches
to IRQ8 I believe.
Mitchell Schoenbrun --------- maschoen@pobox.com