Re: [patch] gettimeofday.2: mention reasons for failure of settimeofday()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Michael,

On Sun, May 13, 2018 at 08:21:44PM +0200, Michael Kerrisk (man-pages) wrote:
> > But then I'm now wondering about the description of CLOCK_MONOTONIC
> > in clock_getes(2):
> > 
> > |     CLOCK_MONOTONIC
> > |            Clock that cannot be set and  represents  monotonic  time
> > |            since some unspecified starting point.
> > 
> > As far as I can see making the range of values the system
> > clock can be set to depend on the value of CLOCK_MONOTONIC
> > requires that CLOCK_MONOTONIC must have a well-defined
> > starting point, rather likely 0 at the moment the system
> > started. If it would start at some random value you never
> > could be sure that you can set the system time to the cur-
> > rent time as CLOCK_MONOTONIC could have started with a
> > larger value.
> 
> Ah yes. Good catch. The description of CLOCK_MONOTONIC follows
> POSIX wording, but on Linux, the "unspecified starting point"
> is the system boot up. When wrote the latest patch, I overlooked
> the fact that the man page was (deliberately) vague on this
> implementation detail. I think it's probably worth making it
> less vague. I changed the description to:
> 
>        CLOCK_MONOTONIC
>               Clock that cannot be  set  and  represents  monotonic  time
>               since—as  described by POSIX—"some unspecified point in the
>               past".  On Linux, that point corresponds to the  number  of
>               seconds  that  the  system  has  been  running since it was
>               booted.
> 
>               The CLOCK_MONOTONIC clock is not affected by  discontinuous
>               jumps in the system time (e.g., if the system administrator
>               manually changes the clock), but is affected by the  incre‐
>               mental  adjustments  performed by adjtime(3) and NTP.  This
>               clock does not count time that the system is suspended.
> 
> Okay?

Perfect;-)

> > Another point is about CLOCK_BOOTTIME:
> > 
> > |     CLOCK_BOOTTIME (since Linux 2.6.39; Linux-specific)
> > |            Identical to CLOCK_MONOTONIC, except it also includes any
> > |            time  that the system is suspended.
> > 
> > The name strongly suggests that it represents the time since
> > the system came up, but if it's tied to CLOCK_MONOTONIC it
> > also could have an arbitrary offset...
> 
> Yes. Another reason to be a little less vague about the starting point
> of CLOCK_MONOTONIC.
> 
> > And, finally, is CLOCK_MONOTONIC_RAW stopped on suspends
> > (and also may have some random offset instead of starting
> > at at system start)?
> 
> Yes, it is stopped on suspends. I've added a sentence to clarify that.

Thank you for clearing this up!

> > The way I read it now there is no clock we can rely on to
> > get incremented at identical time intervals and not to stop
> > on suspends...
> 
> You mean something like CLCOK_BOOTTIME_RAW? You appear to be correct.
> Do you need this?

CLOCK_BOOTTIME_RAW (i.e. CLOCK_MONOTONIC_RAW without being
subject to suspends) would be perfect;-) I don't it need at
the moment, but I guess it wouldn't hurt to be able mea-
sure time differences precisely.

As an example: you have a system that gets data from an electric
energy meter and you also want to be able to return data on the
power, something the meter may nor supply. In that case you'd
approximate the power by measuring energies at regular intervals
and return powers calculated from differences between energies,
divided by the time in between the measurements. But if the
time between the measurements can't be measured precisely the
power values calculated that way could be off quite a bit.

                 Thank you and best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      jt@xxxxxxxxxxx
   \_______________________________      http://toerring.de
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux