Hi all,
We verified the correctness of nanosleep function by means of using the
ClockCycles() services (rdtsc). It looks that nanosleep add a fixed
delay 2-3 ms to the passed value even if the user is requiring few msecs
or usec.
In case of very short delay, have we to revert to use in line loop using
rdtsc ?
We are using QNX 6.1 and patch A.
Thanks,
Enrico
–
| Enrico Bendinelli | Prisma Engineering srl |
| enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |
| This mail was sent using 100% recycled electrons |
Enrico Bendinelli <enricob@prisma-eng.it> wrote in
news:3CD640B6.DCCC8F0E@prisma-eng.it:
We verified the correctness of nanosleep function by means of using the
ClockCycles() services (rdtsc). It looks that nanosleep add a fixed
delay 2-3 ms to the passed value even if the user is requiring few msecs
or usec.
As per the docs, the value you submit is rounded to a multiple of the
system ticksize. I believe that it also adds one to ensure you sleep at
least the amount specified (rounded).
In case of very short delay, have we to revert to use in line loop using
rdtsc ?
Depending how fine grained a delay you want, you may need to do a spin.
Watch out for the rdtsc instruction - depending on what platform you run
on and how long of a delay we’re talking about, it may loop on you (given
the speed of the x86 cpus is going up by .25/.5 Ghz per generation)
\
Cheers,
Adam
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>
Enrico Bendinelli wrote:
It looks that nanosleep add a fixed delay 2-3 ms to the passed value
I’ve also noted the presence of a 2 ms offset. On the system I’ve
tested (P2 @ 400 MHz and P4 @ 1.5 GHz), the value of this offset is
fixed at exactly 2 ms.
At one point, I wrote a wrapper to systematically substract 2 ms from
the requested delay or spin until the time has expired.
It seems there’s nothing else you can do to avoid this problem.
–bl
“Bernard Leclerc” <whittom-leclerc@sympatico.ca> wrote in message
news:ab7e5u$jd3$1@inn.qnx.com…
Enrico Bendinelli wrote:
It looks that nanosleep add a fixed delay 2-3 ms to the passed value
I’ve also noted the presence of a 2 ms offset. On the system I’ve
tested (P2 @ 400 MHz and P4 @ 1.5 GHz), the value of this offset is
fixed at exactly 2 ms.
At one point, I wrote a wrapper to systematically substract 2 ms from
the requested delay or spin until the time has expired.
It seems there’s nothing else you can do to avoid this problem.
It’s not a problem. It’s the documented behavior 
–bl
\