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 <[email protected]> - 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) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
