bug-gnu-utils
[Top][All Lists]
Advanced

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

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


From: Petr Pisar
Subject: Re: time: Should real time usage account discontinous jumps?
Date: Thu, 26 Sep 2013 06:37:06 +0000 (UTC)
User-agent: slrn/1.0.1 (Linux)

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.

> 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.

>> 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.

-- Petr




reply via email to

[Prev in Thread] Current Thread [Next in Thread]