public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Is CLOCK_REALTIME the same as the clock under gettimeofday()
@ 2002-03-27 20:50 george anzinger
  0 siblings, 0 replies; 2+ messages in thread
From: george anzinger @ 2002-03-27 20:50 UTC (permalink / raw)
  To: high-res-timers-discourse, linux-kernel@vger.kernel.org

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Is CLOCK_REALTIME the same as the clock under gettimeofday()
       [not found] <014701c1db2b$d1f537f0$820314ac@fdvlegoll01>
@ 2002-04-03 18:44 ` george anzinger
  0 siblings, 0 replies; 2+ messages in thread
From: george anzinger @ 2002-04-03 18:44 UTC (permalink / raw)
  To: Vincent Legoll, linux-kernel@vger.kernel.org,
	high-res-timers-discourse

Vincent Legoll wrote:
> 
> After reading that message from you on lkml archive, I asked me a question:
> How would you know you have drifted more than one second, if timer expires
> after a very long time ? It'll be too late...

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-04-03 18:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <014701c1db2b$d1f537f0$820314ac@fdvlegoll01>
2002-04-03 18:44 ` Is CLOCK_REALTIME the same as the clock under gettimeofday() george anzinger
2002-03-27 20:50 george anzinger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox