Using the monotonic clock in time(1)?

[Warner Losh]

On Wed, Feb 21, 2018 at 3:22 PM, Alan Somers <asomers at freebsd.org> wrote:

> On Wed, Feb 21, 2018 at 3:14 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Wed, Feb 21, 2018 at 2:33 PM, Alan Somers <asomers at freebsd.org> wrote:
>>
>>> time(1) currently uses the realtime clock, which is undesirable for
>>> timing
>>> short-lived commands while ntpd is active.  I opened a review to add an
>>> option to use the monotonic clock instead, but jilles suggested that time
>>> should use the monotonic clock unconditionally, since that's almost
>>> always
>>> better for measuring short durations.  However, the Open Group's
>>> specification seems to require the real time clock.  What do the
>>> standards
>>> folks think?  Is the Open Group spec sufficiently ambiguous and/or wrong
>>> that we should switch to the monotonic clock instead?
>>>
>>> https://reviews.freebsd.org/D14032
>>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/time.html
>>
>>
>> The issue with ntpd should only be the initial step. After that it steers
>> the frequency of the base clock which affects all clocks. It should be a
>> rare issue that the two clocks give different results.
>>
>> Having said that I see no issue with using a monotonic clock here. I
>> think there's enough wiggle room in the standard to support it. It's really
>> the only clock you can t2-t1 with and get a guaranteed to be meaningful
>> answer. I can't imagine the OpenGroup specifies what happens over a time
>> step the real time clock for programs timed with time. The (real) is in
>> parens, which is not a normative form for specifying the time. I'm not a
>> professional standards lawyer, but my amateur reading says this is a good
>> change.
>>
>> Warner
>>
>
> I was needlessly specific when I said "ntpd".  I should've said "when some
> other process may change the system clock".  For example, Active Directory
> has its own time-synchronization protocol, and at least one AD client will
> step the clock, rather than slew it like ntpd does.
>

How utterly crappy a daemon that is.

Be that as it may, I'm glad to see this change since the monotonic is one
of the few unix clocks you can do t2 - t1 with. It doesn't even suffer from
the leap second problem that all other Unix clocks suffer from.

Warner