Messages in this thread | | | Date | Wed, 27 Mar 2002 12:50:43 -0800 | From | george anzinger <> | Subject | Is CLOCK_REALTIME the same as the clock under gettimeofday() |
| |
A re-reading of the standard (dammed nuisance), to get the man pages right, uncovered the information that clock_nanosleep() with the absolute option is supposed to wake up at the specified time, regardless of intervening calls to clock_settime() (all on CLOCK_REALTIME). In considering how to make this happen, I assumed that this also meant that calls to settime() and adjtime() (i.e. ntp code) should also be covered. All this assumes that CLOCK_REALTIME and the gettimeofday() clock are the same.
The way to do this IMHO, is to put these sleep requests in a linked list and, each time the time is changed, run thru the list and cancel each sleep and redo it. The problem with this is the ntp stuff which makes small adjustments each tick (10 ms). I think this is too much overhead for each tick so I am trying to come up with a new way that has less overhead.
One possible solution is to disconnect CLOCK_REALTIME from the gettimeofday() clock. It could be, for example, connected to the uptime clock (CLOCK_MONOTONIC) with an offset which would be added to get to something close to the gettimeofday() clock. The offset would be calculated at boot time and then periodically from then on. The period could be something that keeps ntp drifting from causing a redo of the clock_nanosleep() calls every tick, but still keeps the clock relatively close, say every second or so (possibly this period could be changed or configured).
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.
comments? -- George 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/
| |