You are right. I am still trying to figure out a sane way to do this.
I suppose we could check from time to time to see what the drift is and
redo all the nanosleep abs timers if it ever drifts more than some
value. We have to redo them when there is a gross clock set anyway, so
we do need to know how to do this.
>
> Did I misread you ? (my english is not omnipotent)
> ---------------------------------------------------------------------------
> -----
> From: george anzinger (george@mvista.com)
> Date: Wed Mar 27 2002 - 15:50:43 EST
>
> Another solution to this issue is to program the clock_nanosleep() calls
> to wake up a second or so prior to the requested time and then fine tune
> the wake up to happen as close as possible to the requested time. This
> calculation might take into account the current ntp drift rate.
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/