Timer Accuracy Problem

Hello NG,

In a recource manager (not multithreaded) I setup a timer (TimerCreate) with
cycletime 20msec .
The timer works. But if I measure the cycletimes I got in about 12% of the
cases
a deviation of 1msec and more.
I run only a minimal configuration without Photon GUI. If I run the programm
with Photon running, I
got only a system load of about 2%. So it can not be a to high load of the
system.
I changed the priority of the recource manager to maximum while the other
processes are at minimum
priority. But nothing helped.
I think this is a little bit bad for a realtime system. With the Venturcom
RTX on Windows NT I do not
have such problems.

Thanks
Patrik

“Cipriano Patrik” <patrik.cipriano@unaxis.com> wrote in
news:a8u6qo$5le$1@inn.qnx.com:

Hello NG,

In a recource manager (not multithreaded) I setup a timer (TimerCreate)
with cycletime 20msec .
The timer works. But if I measure the cycletimes I got in about 12% of
the cases
a deviation of 1msec and more.
I run only a minimal configuration without Photon GUI. If I run the
programm with Photon running, I
got only a system load of about 2%. So it can not be a to high load of
the system.
I changed the priority of the recource manager to maximum while the
other processes are at minimum
priority. But nothing helped.
I think this is a little bit bad for a realtime system. With the
Venturcom RTX on Windows NT I do not
have such problems.

It’s possible that you’re getting hit at the “next” timer tick (wakeup time
= now+req’d time+1 tick), since POSIX says a process cannot sleep for less
time then it asked for (and now is really the last tick).

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

You’re probably expecting the timer to tick at exactly 1 ms intervals. In
actuality, it ticks at 0.999847 ms, so every once in a while it has to
insert an extra tick between your expirations to make it at least 20 ms. In
that case, the interval becomes almost 21 ms.
You can eliminate this factor by specifying your timer interval as
20*999847.

Marty Doane
Siemens Dematic


“Cipriano Patrik” <patrik.cipriano@unaxis.com> wrote in message
news:a8u6qo$5le$1@inn.qnx.com

Hello NG,

In a recource manager (not multithreaded) I setup a timer (TimerCreate)
with
cycletime 20msec .
The timer works. But if I measure the cycletimes I got in about 12% of the
cases
a deviation of 1msec and more.
I run only a minimal configuration without Photon GUI. If I run the
programm
with Photon running, I
got only a system load of about 2%. So it can not be a to high load of the
system.
I changed the priority of the recource manager to maximum while the other
processes are at minimum
priority. But nothing helped.
I think this is a little bit bad for a realtime system. With the Venturcom
RTX on Windows NT I do not
have such problems.

Thanks
Patrik

Does your timer auto repeat or do you reset it after it goes off?
(You should auto-repeat)

“Cipriano Patrik” <patrik.cipriano@unaxis.com> wrote in message
news:a8u6qo$5le$1@inn.qnx.com

Hello NG,

In a recource manager (not multithreaded) I setup a timer (TimerCreate)
with
cycletime 20msec .
The timer works. But if I measure the cycletimes I got in about 12% of the
cases
a deviation of 1msec and more.
I run only a minimal configuration without Photon GUI. If I run the
programm
with Photon running, I
got only a system load of about 2%. So it can not be a to high load of the
system.
I changed the priority of the recource manager to maximum while the other
processes are at minimum
priority. But nothing helped.
I think this is a little bit bad for a realtime system. With the Venturcom
RTX on Windows NT I do not
have such problems.

Thanks
Patrik

It would be possible. But how long is a tick. If it is 1msec it would be
possible.
but i hope it’s smaller.
If I check the time of one cycle with:

dCycleTime =
1.0/(double)SYSPAGE_ENTRY(qtime)->cycles_per_sec*(double)NANOSEC;

I’ve got a cycletime of 3.74 nanasec.

Thanks
Patrik


“Adam Mallory” <amallory@qnx.com> schrieb im Newsbeitrag
news:Xns91EB71CDEF0F3amalloryqnxcom@209.226.137.4

“Cipriano Patrik” <> patrik.cipriano@unaxis.com> > wrote in
news:a8u6qo$5le$> 1@inn.qnx.com> :

Hello NG,

In a recource manager (not multithreaded) I setup a timer (TimerCreate)
with cycletime 20msec .
The timer works. But if I measure the cycletimes I got in about 12% of
the cases
a deviation of 1msec and more.
I run only a minimal configuration without Photon GUI. If I run the
programm with Photon running, I
got only a system load of about 2%. So it can not be a to high load of
the system.
I changed the priority of the recource manager to maximum while the
other processes are at minimum
priority. But nothing helped.
I think this is a little bit bad for a realtime system. With the
Venturcom RTX on Windows NT I do not
have such problems.

It’s possible that you’re getting hit at the “next” timer tick (wakeup
time
= now+req’d time+1 tick), since POSIX says a process cannot sleep for less
time then it asked for (and now is really the last tick).

\

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

I tested this. But it didn’t help.

I start the timer as auto-repeat timer with 20000000 nanosec.
And by the way, what would it need the time in nanosec if I would only have
a resolution of 1msec.

My P266 MHz CPU has a cycletime resolution of 3.74 nanosec.

Thanks
Patrik


“Marty Doane” <marty.doane@rapistan.com> schrieb im Newsbeitrag
news:a8v688$r6q$1@inn.qnx.com

You’re probably expecting the timer to tick at exactly 1 ms intervals. In
actuality, it ticks at 0.999847 ms, so every once in a while it has to
insert an extra tick between your expirations to make it at least 20 ms.
In
that case, the interval becomes almost 21 ms.
You can eliminate this factor by specifying your timer interval as
20*999847.

Marty Doane
Siemens Dematic


“Cipriano Patrik” <> patrik.cipriano@unaxis.com> > wrote in message
news:a8u6qo$5le$> 1@inn.qnx.com> …
Hello NG,

In a recource manager (not multithreaded) I setup a timer (TimerCreate)
with
cycletime 20msec .
The timer works. But if I measure the cycletimes I got in about 12% of
the
cases
a deviation of 1msec and more.
I run only a minimal configuration without Photon GUI. If I run the
programm
with Photon running, I
got only a system load of about 2%. So it can not be a to high load of
the
system.
I changed the priority of the recource manager to maximum while the
other
processes are at minimum
priority. But nothing helped.
I think this is a little bit bad for a realtime system. With the
Venturcom
RTX on Windows NT I do not
have such problems.

Thanks
Patrik
\

“Cipriano Patrik” <patrik.cipriano@unaxis.com> wrote in message
news:a90miq$lt$1@inn.qnx.com

It would be possible. But how long is a tick. If it is 1msec it would be
possible.
but i hope it’s smaller.
If I check the time of one cycle with:

dCycleTime =
1.0/(double)SYSPAGE_ENTRY(qtime)->cycles_per_sec*(double)NANOSEC;

I’ve got a cycletime of 3.74 nanasec.

can’t be. This value is the resolution of the ClockCycles() function, not
that of timer related function. As you mention in another post that
correspond to your CPU frequence of 266Mzh (1/266Mzh = 3.74 ns)

Thanks
Patrik


“Adam Mallory” <> amallory@qnx.com> > schrieb im Newsbeitrag
news:Xns91EB71CDEF0F3amalloryqnxcom@209.226.137.4
“Cipriano Patrik” <> patrik.cipriano@unaxis.com> > wrote in
news:a8u6qo$5le$> 1@inn.qnx.com> :

Hello NG,

In a recource manager (not multithreaded) I setup a timer
(TimerCreate)
with cycletime 20msec .
The timer works. But if I measure the cycletimes I got in about 12% of
the cases
a deviation of 1msec and more.
I run only a minimal configuration without Photon GUI. If I run the
programm with Photon running, I
got only a system load of about 2%. So it can not be a to high load of
the system.
I changed the priority of the recource manager to maximum while the
other processes are at minimum
priority. But nothing helped.
I think this is a little bit bad for a realtime system. With the
Venturcom RTX on Windows NT I do not
have such problems.

It’s possible that you’re getting hit at the “next” timer tick (wakeup
time
= now+req’d time+1 tick), since POSIX says a process cannot sleep for
less
time then it asked for (and now is really the last tick).

\

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

“Cipriano Patrik” <patrik.cipriano@unaxis.com> wrote in message
news:a90moi$tn$1@inn.qnx.com

I tested this. But it didn’t help.

I start the timer as auto-repeat timer with 20000000 nanosec.
And by the way, what would it need the time in nanosec if I would only
have
a resolution of 1msec.

Currently timers resolution are managed via tick interrupt (thus tick rate).
However in the futur or on other CPU it may be possible to increase
that resolution, hence the nanosec. There is possibly a historical
reason for it and compliance with POSIX.

My P266 MHz CPU has a cycletime resolution of 3.74 nanosec.

That’s unrelated to timer precision. The technology required
to implement timer is independant of CPU resolution.
Further more implement timer using CPU resolution could be tricky
because some hardware throttle the CPU frequence.

Thanks
Patrik


“Marty Doane” <> marty.doane@rapistan.com> > schrieb im Newsbeitrag
news:a8v688$r6q$> 1@inn.qnx.com> …
You’re probably expecting the timer to tick at exactly 1 ms intervals.
In
actuality, it ticks at 0.999847 ms, so every once in a while it has to
insert an extra tick between your expirations to make it at least 20 ms.
In
that case, the interval becomes almost 21 ms.
You can eliminate this factor by specifying your timer interval as
20*999847.

Marty Doane
Siemens Dematic


“Cipriano Patrik” <> patrik.cipriano@unaxis.com> > wrote in message
news:a8u6qo$5le$> 1@inn.qnx.com> …
Hello NG,

In a recource manager (not multithreaded) I setup a timer
(TimerCreate)
with
cycletime 20msec .
The timer works. But if I measure the cycletimes I got in about 12% of
the
cases
a deviation of 1msec and more.
I run only a minimal configuration without Photon GUI. If I run the
programm
with Photon running, I
got only a system load of about 2%. So it can not be a to high load of
the
system.
I changed the priority of the recource manager to maximum while the
other
processes are at minimum
priority. But nothing helped.
I think this is a little bit bad for a realtime system. With the
Venturcom
RTX on Windows NT I do not
have such problems.

Thanks
Patrik


\

Now I understand. The timer resolution is 999 usec. Given by History.
But this is disapointing. How do I get a higher resolution?
Shure I can not use the timer functions. I have to write my own timer
process
which will work with the nanospin() function.

I don’t know if I will use QNX for the next project. Because there is the
same. I can not have a variation
of +/- 1 msec.

Thank You
Patrik Cipriano

“Mario Charest” <goto@nothingness.com> schrieb im Newsbeitrag
news:a915ud$cbc$1@inn.qnx.com

“Cipriano Patrik” <> patrik.cipriano@unaxis.com> > wrote in message
news:a90miq$lt$> 1@inn.qnx.com> …
It would be possible. But how long is a tick. If it is 1msec it would be
possible.
but i hope it’s smaller.
If I check the time of one cycle with:

dCycleTime =
1.0/(double)SYSPAGE_ENTRY(qtime)->cycles_per_sec*(double)NANOSEC;

I’ve got a cycletime of 3.74 nanasec.

can’t be. This value is the resolution of the ClockCycles() function, not
that of timer related function. As you mention in another post that
correspond to your CPU frequence of 266Mzh (1/266Mzh = 3.74 ns)


Thanks
Patrik


“Adam Mallory” <> amallory@qnx.com> > schrieb im Newsbeitrag
news:Xns91EB71CDEF0F3amalloryqnxcom@209.226.137.4
“Cipriano Patrik” <> patrik.cipriano@unaxis.com> > wrote in
news:a8u6qo$5le$> 1@inn.qnx.com> :

Hello NG,

In a recource manager (not multithreaded) I setup a timer
(TimerCreate)
with cycletime 20msec .
The timer works. But if I measure the cycletimes I got in about 12%
of
the cases
a deviation of 1msec and more.
I run only a minimal configuration without Photon GUI. If I run the
programm with Photon running, I
got only a system load of about 2%. So it can not be a to high load
of
the system.
I changed the priority of the recource manager to maximum while the
other processes are at minimum
priority. But nothing helped.
I think this is a little bit bad for a realtime system. With the
Venturcom RTX on Windows NT I do not
have such problems.

It’s possible that you’re getting hit at the “next” timer tick (wakeup
time
= now+req’d time+1 tick), since POSIX says a process cannot sleep for
less
time then it asked for (and now is really the last tick).

\

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
\

“Cipriano Patrik” <patrik.cipriano@unaxis.com> wrote in message
news:a91c8k$grb$1@inn.qnx.com

Now I understand. The timer resolution is 999 usec. Given by History.
But this is disapointing. How do I get a higher resolution?
Shure I can not use the timer functions. I have to write my own timer
process
which will work with the nanospin() function.

nanospin will consume all the CPU, not a good idea.

I don’t know if I will use QNX for the next project. Because there is the
same. I can not have a variation of +/- 1 msec.

You can increase it to 500us.

How can I increase it to 500usec?

This would be enough accurate for me.

Thank You
Patrik

“Mario Charest” <goto@nothingness.com> schrieb im Newsbeitrag
news:a91g70$jsf$1@inn.qnx.com

“Cipriano Patrik” <> patrik.cipriano@unaxis.com> > wrote in message
news:a91c8k$grb$> 1@inn.qnx.com> …
Now I understand. The timer resolution is 999 usec. Given by History.
But this is disapointing. How do I get a higher resolution?
Shure I can not use the timer functions. I have to write my own timer
process
which will work with the nanospin() function.

nanospin will consume all the CPU, not a good idea.


I don’t know if I will use QNX for the next project. Because there is
the
same. I can not have a variation of +/- 1 msec.

You can increase it to 500us.
\

“Cipriano Patrik” <patrik.cipriano@unaxis.com> wrote in message
news:a91k1g$mf1$1@inn.qnx.com

How can I increase it to 500usec?

This would be enough accurate for me.

I’m not sure it would solve your problem though. Look at function
ClockPeriod().

You should still specify a time that is a multiple of the hardware timer
which is
0.999847 us

Have a look at:

http://qdn.qnx.com/articles/oct2300/quantization.html
http://qdn.qnx.com/articles/oct3100/concept_of_time.html

Thank You
Patrik

“Mario Charest” <> goto@nothingness.com> > schrieb im Newsbeitrag
news:a91g70$jsf$> 1@inn.qnx.com> …

“Cipriano Patrik” <> patrik.cipriano@unaxis.com> > wrote in message
news:a91c8k$grb$> 1@inn.qnx.com> …
Now I understand. The timer resolution is 999 usec. Given by History.
But this is disapointing. How do I get a higher resolution?
Shure I can not use the timer functions. I have to write my own timer
process
which will work with the nanospin() function.

nanospin will consume all the CPU, not a good idea.


I don’t know if I will use QNX for the next project. Because there is
the
same. I can not have a variation of +/- 1 msec.

You can increase it to 500us.


\

Cipriano Patrik wrote:

How can I increase it to 500usec?

This would be enough accurate for me.

I don’t think you’re hearing what is being said.


The problem is a function of the PC hardware and has nothing

to do with the operating system. In order to get precise 1ms

timing you must use a different interrupt source (on the PC

this usually means using the RTC interrupt).


There is no way that any OS can provide “precise” 1ms timing

on the PC without using the RTC interrupt, or some sort of
external timer interrupt. Often the PC value is close enough
for many applications (e.g. if you require 2x oversampling of
a 500hz signal, then the fact that your sampling is a tiny bit
faster than 1Khz usually isn’t a problem).

Remember that Venturcoms’ solution is not Posix compliant hence
the semantics of the synthetic timer are up to Venturecom;
perhaps they decided that it was OK if you got called before
the time expired (i.e. they decided on your behalf that the PC
timer was “close enough” to 1Khz ?) This might be OK for an OS
that only runs on PC’s (and where 1ms is actually considered to
be a short period), but QNX (where 1ms is a long time) and Posix
are intended to be a architecture neutral solution (isn’t that a
requirement for portability ?).

Since you don’t seem to be adverse to tying yourself to the PC
architecture, I have attached source for using the RTC on a PC
under QNX.

Rennie

Thank You for the help.

I will try with the RTC Interrupt.

Best Regards
Patrik Cipriano


“Cipriano Patrik” <patrik.cipriano@unaxis.com> schrieb im Newsbeitrag
news:a91k1g$mf1$1@inn.qnx.com

How can I increase it to 500usec?

This would be enough accurate for me.

Thank You
Patrik

“Mario Charest” <> goto@nothingness.com> > schrieb im Newsbeitrag
news:a91g70$jsf$> 1@inn.qnx.com> …

“Cipriano Patrik” <> patrik.cipriano@unaxis.com> > wrote in message
news:a91c8k$grb$> 1@inn.qnx.com> …
Now I understand. The timer resolution is 999 usec. Given by History.
But this is disapointing. How do I get a higher resolution?
Shure I can not use the timer functions. I have to write my own timer
process
which will work with the nanospin() function.

nanospin will consume all the CPU, not a good idea.


I don’t know if I will use QNX for the next project. Because there is
the
same. I can not have a variation of +/- 1 msec.

You can increase it to 500us.


\