Re: hard crash on leap second
On 2009-01-01 11:58:14 -0700, Paul E Condon wrote:
> IMHO, chrony's current behavior is already 'correct'. To me, it is
> far more important that the reported time is always increasing than
> that it quickly settles into synchronism with a source that exhibits
> sudden jumps or extended periods of stasis.
I agree that sudden jumps or extended periods of stasis are bad.
However this is how leap seconds currently work (it would have been
better to have a continuous synchronization between UTC and UT1[*]).
The consequence is that a machine using chrony can have 1 second
difference with other machines. When the files are stored remotely
(e.g. on a NFS server), this can yield problems, especially with
tools like "make" (even though one doesn't like tools based on
timestamps).
[*] According to Wikipedia, a vote towards this solution was planned
in 2008. But Wikipedia is not up-to-date.
> Real time clocks are a quantized form of time, with the quantum
> being the period of the cpu 'clock'. Reporting system event times to
> a precision of 1e-9 sec, as in done in the kernel, is crazy. The
> last digit of that 'time' is surely not accurate.
Isn't the goal is to avoid equalities or to have accurate *relative*
times on a machine?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Reply to: