nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Michael Kerrisk]

Thomas,

(I gues you are the right target for this?)

The POSIX.1 specification of nanosleep() says:

        But, except for the case of being interrupted by a signal, the
        suspension time shall not be less than the time  specified  by
        rqtp, as measured by the system clock CLOCK_REALTIME.


However, reading kernel/hrtimer.c:sys_nanosleep(), it appears that
CLOCK_MONOTONIC is used.

     return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC);

Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
intentional?  If yes, then I should document this in the man-pages.  If not,
then it should be fixed.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages onlne: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Bart Van Assche]

On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
> Thomas,
>
> (I gues you are the right target for this?)
>
> The POSIX.1 specification of nanosleep() says:
>
>       But, except for the case of being interrupted by a signal, the
>       suspension time shall not be less than the time  specified  by
>       rqtp, as measured by the system clock CLOCK_REALTIME.
>
>
> However, reading kernel/hrtimer.c:sys_nanosleep(), it appears that
> CLOCK_MONOTONIC is used.
>
>    return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
>
> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
> intentional?  If yes, then I should document this in the man-pages.  If not,
> then it should be fixed.

CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
backward, CLOCK_REALTIME not. So the man page should be fixed.

Strange to find such phrases in the POSIX specs ...

Bart.

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Michael Kerrisk]

Bart,

On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
<bart.vanassche@gmail.com> wrote:
> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>> Thomas,
>>
>> (I gues you are the right target for this?)
>>
>> The POSIX.1 specification of nanosleep() says:
>>
>>       But, except for the case of being interrupted by a signal, the
>>       suspension time shall not be less than the time  specified  by
>>       rqtp, as measured by the system clock CLOCK_REALTIME.
>>
>>
>> However, reading kernel/hrtimer.c:sys_nanosleep(), it appears that
>> CLOCK_MONOTONIC is used.
>>
>>    return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
>>
>> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
>> intentional?  If yes, then I should document this in the man-pages.  If not,
>> then it should be fixed.
>
> CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
> backward, CLOCK_REALTIME not. So the man page should be fixed.

Thanks for your reply, but I'm not quite convinced yet.  The things
is: the Solaris man page also says "CLOCK_REALTIME".  (Of course that
man page may just be parroting the standard.)  Could there not be some
reasonable semantics for a nanosleep() that was based on
CLOCK_REALTIME?

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Bart Van Assche]

On Mon, Jun 23, 2008 at 11:48 AM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
> On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
> <bart.vanassche@gmail.com> wrote:
>> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>> The POSIX.1 specification of nanosleep() says:
>>>
>>>       But, except for the case of being interrupted by a signal, the
>>>       suspension time shall not be less than the time  specified  by
>>>       rqtp, as measured by the system clock CLOCK_REALTIME.
>>>
>>>
>>> However, reading kernel/hrtimer.c:sys_nanosleep(), it appears that
>>> CLOCK_MONOTONIC is used.
>>>
>>>    return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
>>>
>>> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
>>> intentional?  If yes, then I should document this in the man-pages.  If not,
>>> then it should be fixed.
>>
>> CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
>> backward, CLOCK_REALTIME not. So the man page should be fixed.
>
> Thanks for your reply, but I'm not quite convinced yet.  The things
> is: the Solaris man page also says "CLOCK_REALTIME".  (Of course that
> man page may just be parroting the standard.)  Could there not be some
> reasonable semantics for a nanosleep() that was based on
> CLOCK_REALTIME?

Sorry, but I don't think that a nanosleep() based on CLOCK_REALTIME
would have reasonable semantics. The first line of the description in
nanosleep()'s manpage says:
"nanosleep()  delays  the  execution  of  the program for at least the
time specified in *req". So you really need CLOCK_MONOTONIC and not
CLOCK_REALTIME.

The reason why CLOCK_REALTIME is mentioned is probably because other
POSIX man pages define three types of clocks: real, virtual and
profiiling. See e.g. the getitimer() man page
(http://www.opengroup.org/onlinepubs/009695399/functions/setitimer.html).
And an overview of all clock types defined by POSIX can be found here:
http://www.opengroup.org/onlinepubs/000095399/functions/clock_getres.html.

Bart.

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Michael Kerrisk]

On Mon, Jun 23, 2008 at 1:56 PM, Bart Van Assche
<bart.vanassche@gmail.com> wrote:
> On Mon, Jun 23, 2008 at 11:48 AM, Michael Kerrisk
> <mtk.manpages@googlemail.com> wrote:
>> On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
>> <bart.vanassche@gmail.com> wrote:
>>> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>>> The POSIX.1 specification of nanosleep() says:
>>>>
>>>>       But, except for the case of being interrupted by a signal, the
>>>>       suspension time shall not be less than the time  specified  by
>>>>       rqtp, as measured by the system clock CLOCK_REALTIME.
>>>>
>>>>
>>>> However, reading kernel/hrtimer.c:sys_nanosleep(), it appears that
>>>> CLOCK_MONOTONIC is used.
>>>>
>>>>    return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
>>>>
>>>> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
>>>> intentional?  If yes, then I should document this in the man-pages.  If not,
>>>> then it should be fixed.
>>>
>>> CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
>>> backward, CLOCK_REALTIME not. So the man page should be fixed.
>>
>> Thanks for your reply, but I'm not quite convinced yet.  The things
>> is: the Solaris man page also says "CLOCK_REALTIME".  (Of course that
>> man page may just be parroting the standard.)  Could there not be some
>> reasonable semantics for a nanosleep() that was based on
>> CLOCK_REALTIME?
>
> Sorry, but I don't think that a nanosleep() based on CLOCK_REALTIME
> would have reasonable semantics. The first line of the description in
> nanosleep()'s manpage says:
> "nanosleep()  delays  the  execution  of  the program for at least the
> time specified in *req". So you really need CLOCK_MONOTONIC and not
> CLOCK_REALTIME.

I don't think it's sufficient to quote the man page here ;-).  That
sentence is really just an abridged version of the sentence that I
quoted from the spec at the start of this thread:

#       But, except for the case of being interrupted by a signal, the
#       suspension time shall not be less than the time  specified  by
#       rqtp, as measured by the system clock CLOCK_REALTIME.

I assume that the author of the man page simply neglected to mention
which clock the syscall measures by.

> The reason why CLOCK_REALTIME is mentioned is probably because other
> POSIX man pages define three types of clocks: real, virtual and
> profiiling. See e.g. the getitimer() man page
> (http://www.opengroup.org/onlinepubs/009695399/functions/setitimer.html).
> And an overview of all clock types defined by POSIX can be found here:
> http://www.opengroup.org/onlinepubs/000095399/functions/clock_getres.html.

I don't *think* this really provides a rationale for why POSIX talks
of CLOCK_REALTIME rather than CLOCK_MONOTONIC when specifying
nanosleep().


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Michael Kerrisk]

On Mon, Jun 23, 2008 at 1:56 PM, Bart Van Assche
<bart.vanassche@gmail.com> wrote:
> On Mon, Jun 23, 2008 at 11:48 AM, Michael Kerrisk
> <mtk.manpages@googlemail.com> wrote:
>> On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
>> <bart.vanassche@gmail.com> wrote:
>>> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>>> The POSIX.1 specification of nanosleep() says:
>>>>
>>>>       But, except for the case of being interrupted by a signal, the
>>>>       suspension time shall not be less than the time  specified  by
>>>>       rqtp, as measured by the system clock CLOCK_REALTIME.
>>>>
>>>>
>>>> However, reading kernel/hrtimer.c:sys_nanosleep(), it appears that
>>>> CLOCK_MONOTONIC is used.
>>>>
>>>>    return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
>>>>
>>>> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
>>>> intentional?  If yes, then I should document this in the man-pages.  If not,
>>>> then it should be fixed.
>>>
>>> CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
>>> backward, CLOCK_REALTIME not. So the man page should be fixed.
>>
>> Thanks for your reply, but I'm not quite convinced yet.  The things
>> is: the Solaris man page also says "CLOCK_REALTIME".  (Of course that
>> man page may just be parroting the standard.)  Could there not be some
>> reasonable semantics for a nanosleep() that was based on
>> CLOCK_REALTIME?
>
> Sorry, but I don't think that a nanosleep() based on CLOCK_REALTIME
> would have reasonable semantics. The first line of the description in
> nanosleep()'s manpage says:
> "nanosleep()  delays  the  execution  of  the program for at least the
> time specified in *req". So you really need CLOCK_MONOTONIC and not
> CLOCK_REALTIME.

I meant to add.  It seems to me that there really could be reasonable
semantics here: nanosleep() sleeps until the specified time has
elapsed, as measured by CLOCK_REALTIME.  That may mean, for example,
that the sleep finishes "early" if CLOCK_REALTIME jumps forward for
some reason.  That seems perfectly reasonable as  possible semantics
for sleeping (i.e., we are interested in sleeping for an interval
based on what the system understands the time to be in the "outside
world").  Note that POSIX also specifies clcok_nanosleep(), which
allows CLOCK_REALTIME and CLOCK_MONOTONIC, and is again explicit about
what nanosleep() should be doing:

  APPLICATION USAGE
       Calling clock_nanosleep() with the value TIMER_ABSTIME not  set
       in  the flags argument and with a clock_id of CLOCK_REALTIME is
       equivalent to calling nanosleep() with the same rqtp  and  rmtp
       arguments.

  RATIONALE
       The  nanosleep()  function specifies that the system-wide clock
       CLOCK_REALTIME is used to measure the  elapsed  time  for  this
       time  service.  However, with the introduction of the monotonic
       clock CLOCK_MONOTONIC a new relative sleep function  is  needed
       to  allow an application to take advantage of the special char-
       acteristics of this clock.

Cheers,

Michael

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Roman Zippel]

Hi,

On Mon, 23 Jun 2008, Michael Kerrisk wrote:

> >> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
> >> intentional?  If yes, then I should document this in the man-pages.  If not,
> >> then it should be fixed.
> >
> > CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
> > backward, CLOCK_REALTIME not. So the man page should be fixed.
> 
> Thanks for your reply, but I'm not quite convinced yet.  The things
> is: the Solaris man page also says "CLOCK_REALTIME".  (Of course that
> man page may just be parroting the standard.)  Could there not be some
> reasonable semantics for a nanosleep() that was based on
> CLOCK_REALTIME?

CLOCK_MONOTONIC is optional, that's probably the reason it's not mentioned 
there. If you check the man page for clock_settime, it specifically 
mentions that pending relative timer (including nanosleep) aren't affected 
by the changed time, thus if CLOCK_MONOTONIC and CLOCK_REALTIME advance 
equally, it doesn't matter which you use for relative timer.

bye, Roman

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Michael Kerrisk]

Roman,

On Mon, Jun 23, 2008 at 2:43 PM, Roman Zippel <zippel@linux-m68k.org> wrote:
> Hi,
>
> On Mon, 23 Jun 2008, Michael Kerrisk wrote:
>
>> >> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
>> >> intentional?  If yes, then I should document this in the man-pages.  If not,
>> >> then it should be fixed.
>> >
>> > CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
>> > backward, CLOCK_REALTIME not. So the man page should be fixed.
>>
>> Thanks for your reply, but I'm not quite convinced yet.  The things
>> is: the Solaris man page also says "CLOCK_REALTIME".  (Of course that
>> man page may just be parroting the standard.)  Could there not be some
>> reasonable semantics for a nanosleep() that was based on
>> CLOCK_REALTIME?
>
> CLOCK_MONOTONIC is optional, that's probably the reason it's not mentioned
> there.

This seems a little unlikely.  POSIX specifies clock_nanosleep() (see
my other reply) specifically to allow for clocks other than
CLOCK_REALTIME.

> If you check the man page for clock_settime, it specifically
> mentions that pending relative timer (including nanosleep) aren't affected
> by the changed time, thus if CLOCK_MONOTONIC and CLOCK_REALTIME advance
> equally, it doesn't matter which you use for relative timer.

Well, I was going to say that that's just a man page, and man page
authors are fallible ;-).  But then I went and had a look at the POSIX
spec for clock_settime().  It includes the following paragraph:

       Setting the value of the CLOCK_REALTIME  clock  via  clock_set-
       time() shall have no effect on threads that are blocked waiting
       for a relative time service based upon  this  clock,  including
       the  nanosleep()  function;  nor  on the expiration of relative
       timers  based  upon  this  clock.   Consequently,  these   time
       services  shall  expire  when  the  requested relative interval
       elapses, independently of the new or old value of the clock.

So that rather flatly contradicts the alternative semantics that I
suggested were possible in my reply to Bart a few minutes ago.

So in my reading of things now, it looks as though the Linux
implementation is probably fine, since the fact that relative
timers/sleeps are explicitly unaffected by jumps in CLOCK_REALTIME
means that the semantics are effectively the same as if the relative
interval was measured against CLOCK_MONOTONIC (unless the two clocks
counted time at different rates; not sure if that  would be possible
in theory, but certainly seems very unlikely in practice).

I'll add some text (not quite sure what yet) in the nanosleep() man
page on this point.

Thanks Roman, Bart.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Bart Van Assche]

On Tue, Jun 24, 2008 at 7:39 AM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
> I'll add some text (not quite sure what yet) in the nanosleep() man
> page on this point.

You could e.g. mention that nanosleep() is neither affected by the
settimeofday() system call nor by adjtimex() (this last one is used by
ntpd).

Bart.

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Michael Kerrisk]

On Tue, Jun 24, 2008 at 10:01 AM, Bart Van Assche
<bart.vanassche@gmail.com> wrote:
> On Tue, Jun 24, 2008 at 7:39 AM, Michael Kerrisk
> <mtk.manpages@googlemail.com> wrote:
>> I'll add some text (not quite sure what yet) in the nanosleep() man
>> page on this point.
>
> You could e.g. mention that nanosleep() is neither affected by the
> settimeofday() system call

Thanks.  Yes, that follows fairly naturally from the statement about
clock_settime().

> nor by adjtimex() (this last one is used by
> ntpd).

That surprised me a little.  So gradual adjustments to the time made
by adjtime() / adjtimex() really don't affect nanosleep()?

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Bart Van Assche]

>> nor by adjtimex() (this last one is used by ntpd).
>
> That surprised me a little.  So gradual adjustments to the time made
> by adjtime() / adjtimex() really don't affect nanosleep()?

Does the adjtime() system call still exist ? I could not find any
information about this system call in the 2.6.25 kernel source code.

Frequency adjustments made via the adjtimex() system call do affect
nanosleep() of course (via timex::freq and/or timex::tick). Stepwise
time adjustments, whether gradual or not, should not affect
nanosleep().

Bart.

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Michael Kerrisk]

On Tue, Jun 24, 2008 at 11:27 AM, Bart Van Assche
<bart.vanassche@gmail.com> wrote:
>>> nor by adjtimex() (this last one is used by ntpd).
>>
>> That surprised me a little.  So gradual adjustments to the time made
>> by adjtime() / adjtimex() really don't affect nanosleep()?
>
> Does the adjtime() system call still exist ? I could not find any
> information about this system call in the 2.6.25 kernel source code.

It's the glibc interface on top of adtimex().  (Sorry, maybe I should
have writte andjtime(3) to be clearer.)

> Frequency adjustments made via the adjtimex() system call do affect
> nanosleep() of course (via timex::freq and/or timex::tick). Stepwise
> time adjustments, whether gradual or not, should not affect
> nanosleep().

Ahhh good -- that makes sense.  Thanks for that info.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Thomas Gleixner]

On Tue, 24 Jun 2008, Michael Kerrisk wrote:
> > If you check the man page for clock_settime, it specifically
> > mentions that pending relative timer (including nanosleep) aren't affected
> > by the changed time, thus if CLOCK_MONOTONIC and CLOCK_REALTIME advance
> > equally, it doesn't matter which you use for relative timer.
> 
> Well, I was going to say that that's just a man page, and man page
> authors are fallible ;-).  But then I went and had a look at the POSIX
> spec for clock_settime().  It includes the following paragraph:
> 
>        Setting the value of the CLOCK_REALTIME  clock  via  clock_set-
>        time() shall have no effect on threads that are blocked waiting
>        for a relative time service based upon  this  clock,  including
>        the  nanosleep()  function;  nor  on the expiration of relative
>        timers  based  upon  this  clock.   Consequently,  these   time
>        services  shall  expire  when  the  requested relative interval
>        elapses, independently of the new or old value of the clock.
> 
> So that rather flatly contradicts the alternative semantics that I
> suggested were possible in my reply to Bart a few minutes ago.
> 
> So in my reading of things now, it looks as though the Linux
> implementation is probably fine, since the fact that relative
> timers/sleeps are explicitly unaffected by jumps in CLOCK_REALTIME
> means that the semantics are effectively the same as if the relative
> interval was measured against CLOCK_MONOTONIC (unless the two clocks
> counted time at different rates; not sure if that  would be possible
> in theory, but certainly seems very unlikely in practice).

We use CLOCK_MONOTONIC for the relative timeouts simply to avoid
trickery vs. clock_settime(CLOCK_REALTIME). That's an kernel internal
implementation detail which does not have any visible effect to the
user space interface.

CLOCK_MONOTONIC and CLOCK_REALTIME are using the same timebase
internally and therefor we can safely use CLOCK_MONOTONIC for the
relative timeouts.

Thanks,

	tglx

Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

[Michael Kerrisk]

On Wed, Jun 25, 2008 at 8:13 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 24 Jun 2008, Michael Kerrisk wrote:
>> > If you check the man page for clock_settime, it specifically
>> > mentions that pending relative timer (including nanosleep) aren't affected
>> > by the changed time, thus if CLOCK_MONOTONIC and CLOCK_REALTIME advance
>> > equally, it doesn't matter which you use for relative timer.
>>
>> Well, I was going to say that that's just a man page, and man page
>> authors are fallible ;-).  But then I went and had a look at the POSIX
>> spec for clock_settime().  It includes the following paragraph:
>>
>>        Setting the value of the CLOCK_REALTIME  clock  via  clock_set-
>>        time() shall have no effect on threads that are blocked waiting
>>        for a relative time service based upon  this  clock,  including
>>        the  nanosleep()  function;  nor  on the expiration of relative
>>        timers  based  upon  this  clock.   Consequently,  these   time
>>        services  shall  expire  when  the  requested relative interval
>>        elapses, independently of the new or old value of the clock.
>>
>> So that rather flatly contradicts the alternative semantics that I
>> suggested were possible in my reply to Bart a few minutes ago.
>>
>> So in my reading of things now, it looks as though the Linux
>> implementation is probably fine, since the fact that relative
>> timers/sleeps are explicitly unaffected by jumps in CLOCK_REALTIME
>> means that the semantics are effectively the same as if the relative
>> interval was measured against CLOCK_MONOTONIC (unless the two clocks
>> counted time at different rates; not sure if that  would be possible
>> in theory, but certainly seems very unlikely in practice).
>
> We use CLOCK_MONOTONIC for the relative timeouts simply to avoid
> trickery vs. clock_settime(CLOCK_REALTIME). That's an kernel internal
> implementation detail which does not have any visible effect to the
> user space interface.
>
> CLOCK_MONOTONIC and CLOCK_REALTIME are using the same timebase
> internally and therefor we can safely use CLOCK_MONOTONIC for the
> relative timeouts.

Thanks Thomas -- that's what I was beginning to understand, butit's
nice to have confirmation.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html