Is CLOCK_REALTIME the same as the clock under gettimeofday()

[george anzinger]

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           [e-mail]
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