Using the monotonic clock in time(1)?

[Alan Somers]

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.

-Alan