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

Re: hard crash on leap second



On Thu, Jan 01, 2009 at 11:56:29AM -0600, John Hasler wrote:
> 
...
> Chrony does not currently support leap seconds [1].  When the leap occurred
> it lost synch, chose a different server, and then pulled back in.

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.

> Have you looked at the version in Experimental with the real-time
> enhancements?  They should reduce latency variation but I don't have a way
> to test that.

Actually, I think people are obsessive about time on computers. My
comment about special relativity can be expanded to an assertion that
there is surely no universally correct way to report time across all
possible reference frames.

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. Computers are, after all, electronics devices that 
operate in the real physical world, at real physical speeds. Only virtual
computers operate in virtual time. 

> 
> > And, the idea of leap seconds is something of an intellectual
> > abomination, anyway.
> 
> Leap seconds should be kept in a file somewhere and appled when formatting
> time for display like DST rules.  They don't belong in the timestream.
> 
   Yes. But there are a lot of social issues. Six and a half billion people,
   of which perhaps a billion think they really know what time is ...

> 
> [1] A reasonable-looking patch to add leap second support was posted to the
> development list yesterday but I did not have time enough to apply and test
> it.

Don't rush to fix something that really isn't broken.

Again, thanks for keeping chrony working so nicely.

-- 
Paul E Condon           
pecondon@mesanetworks.net


Reply to: