> oneshot mode. Periodically, the next wake up date is calculated in clock
> units. Because the period in clock unit is not equal to the period in
> nanoseconds, a drift should be seen, especially after a large number of
> periods.
>
> In fact, after having done this test, I did not see such a drift. Do not
> think I am disapointed, I'm not ! I would like to know wether I am wrong
> in my assumptions or not, and if not, how the gethrtime function manages
> not to create a drift.
I don't know wether you're wrong in your assumptions but a couple of weeks
ago I was working on some steppermotor software and there there was
obviously some drift when just using a call (for constant speed)
while(1)
{
pthread_make_periodic_np(pthread_self(),gethrtime()+period,0);
pthread_wait_np();
outb(...);
}
I don't know wether the drift is due to the rounding process, but the
jitter alone is responsible for drift.
To avoid drifting errors you can use "absolute timing", ie something like
next_fire_time = somewhere in the future;
while(1)
{
pthread_make_periodic_np(pthread_self(),next_fire_time,0);
pthread_wait_np();
outb(...);
next_fire_time += period;
}
Hope this was somewhat an answer to your question,
regards
klaas
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
