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
On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <[email protected]> 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.
Bart,
On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
<[email protected]> wrote:
> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <[email protected]> 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
On Mon, Jun 23, 2008 at 11:48 AM, Michael Kerrisk
<[email protected]> wrote:
> On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
> <[email protected]> wrote:
>> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <[email protected]> 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.
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
On Mon, Jun 23, 2008 at 1:56 PM, Bart Van Assche
<[email protected]> wrote:
> On Mon, Jun 23, 2008 at 11:48 AM, Michael Kerrisk
> <[email protected]> wrote:
>> On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
>> <[email protected]> wrote:
>>> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <[email protected]> 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
On Mon, Jun 23, 2008 at 1:56 PM, Bart Van Assche
<[email protected]> wrote:
> On Mon, Jun 23, 2008 at 11:48 AM, Michael Kerrisk
> <[email protected]> wrote:
>> On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
>> <[email protected]> wrote:
>>> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <[email protected]> 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
Roman,
On Mon, Jun 23, 2008 at 2:43 PM, Roman Zippel <[email protected]> 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
On Tue, Jun 24, 2008 at 7:39 AM, Michael Kerrisk
<[email protected]> 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.
On Tue, Jun 24, 2008 at 10:01 AM, Bart Van Assche
<[email protected]> wrote:
> On Tue, Jun 24, 2008 at 7:39 AM, Michael Kerrisk
> <[email protected]> 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
>> 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.
On Tue, Jun 24, 2008 at 11:27 AM, Bart Van Assche
<[email protected]> 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
On Wed, Jun 25, 2008 at 8:13 AM, Thomas Gleixner <[email protected]> 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
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