Re: time: Should real time usage account discontinous jumps?

[Petr Pisar]

On Thu, Sep 26, 2013 at 08:09:16AM -0700, Charles Swiger wrote:
> On Sep 25, 2013, at 11:37 PM, Petr Pisar <address@hidden> wrote:
> > On 2013-09-26, Bob Proulx <address@hidden> wrote:
> >> Petr Pisar wrote:
> >>> The GNU time as well as bash built-in compute real time process usage as
> >>> a simple difference between two real time points. If there was a time
> >>> adjustement in between (by NTP or manual), the meassured value would be
> >>> affected.
> >> 
> >> NTP will never step the clock.  NTP will adjust the time of each clock
> >> tick to keep the clock on time and so that every tick is present.  If
> >> the clock is being step'd it would be due to other reasons such as
> >> manually.
> > 
> > NTP does not step, NTP slows or accelerates real time. But the effect is
> > the same---the time point difference mismatches physical duration.
> 
> NTP calls adjtime() or similar to adjust the rate that the system clock [1]
> increments it's notion of time to match "real time" obtained from the NTP
> timesource, which is either a lower-stratum NTPd server via the Internet,
> or a primary time reference like a GPS sensor or atomic clock.
> 
> >> But why would there be a time adjustment between?  Stepping the clock
> >> is an abnormal condition.  It isn't something that should ever happen
> >> during normal system operation.  If your clock is being stepped then
> >> that is a bug and needs to be fixed.
> > 
> > NTP per definition refuses to adjust clock if the difference is too big.
> > Thus distributions usually step the clock on first NTP contact, and then
> > keep adjusting. With mobile hosts loosing and getting network
> > connectivity on the fly, it's quite possible the system will experience
> > time steps.
> 
> Oh, agreed.
> 
> For the normal case, ntpd won't change time faster than 0.5 ms per second,
> but if the sample interval is long enough to contain network dropout and
> re-acquisition, then ntpd might be restarted and do an initial step of time
> rather than the slew rate.
> 
> However, on a good day, ntpd will have already figured out the intrinsic
> first-order deviation of the local HW clock versus "real time", and the
> device will continue to keep better time as a result even thru a network
> outage than it would otherwise.
> 
> >>> I have found any hint nowhere if this is intended behavior or if one
> >>> should meassure some kind of monotic time line.
> >> 
> >> Since stepping the clock is not a normal condition I don't think it
> >> matters.  It certainly isn't a problem if the system is running NTP
> >> and the clock is running normally.
> > 
> > I agree one can consider NTP-adjusted clock as `running normally'. Because
> > the reason for adjustment is that local real clock is not accurate
> > enough. In this light, CLOCK_MONOTONIC seems good enough.
> 
> Yes, if you want to compute "how long something took" via delta between start
> and finish, then using CLOCK_MONOTONIC is likely the best choice.
> 
Please excuse resurrecting this old story. I forgot it and now I found it.
Two patches are attached that should implement the idea discuessed in this
thread.

The first patch corrects configure.in because the old syntax does not work
with my autotools anymore. The second patch is the implementation of the time
measurement with clock_gettime(CLOCK_MONOTONIC).

-- Petr

0001-Modernize-configure.in.patch
Description: Text document

0002-Prefer-clock_gettime-CLOCK_MONOTONIC.patch
Description: Text document

signature.asc
Description: PGP signature