Using the monotonic clock in time(1)?

Warner Losh imp at
Wed Feb 21 22:56:56 UTC 2018

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

> On Wed, Feb 21, 2018 at 3:14 PM, Warner Losh <imp at> wrote:
>> On Wed, Feb 21, 2018 at 2:33 PM, Alan Somers <asomers at> 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?
>> 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.


More information about the freebsd-standards mailing list