[arch-general] Leap seconds ntp and chrony?

[Leonid Isaev]

On Wed, 04 Jul 2012 22:06:27 +0100
Mauro Santos <registo.mailling at gmail.com> wrote:

> On 04-07-2012 21:00, Tom Gundersen wrote:
> > On Wed, Jul 4, 2012 at 9:06 PM, Kevin Chadwick <ma1l1ists at yahoo.co.uk>
> > wrote:
> >>> If you have a
> >>> mercurial/git installation even in a small group, I am sure you'll prefer
> >>> accurate timestamps in your commit history. And the list goes on...
> >>
> >> I believe an RTC is perfectly capable of that.
> > 
> > I tried to find some data on what to expect from RTC's. I was not very
> > successful, except finding people citing 80-100PPM as typical drift
> > rates (~8 secs/day).
> 
> From data I have access to, taken from machines running ntpd, I can say
> the following about the drift in PPM stored in ntpd's drift file:
> 
> my laptop: -9.699
> machine 1: -8.762
> machine 2: -443.266
> machine 3: -35.417
> 
> Machine 1 is the newest and machine 3 is the oldest.

AFAIK comparing RTCs on different machines is meaningless because there seem
to be no quality handle for RTC. So, RTC may exist or not, but you can't
choose (and therefore guarantee) to have a good RTC, at least on consumer (not
server) motherboards. NTPD on the other hand implements a protocol $\equiv$
standard.

FWIW, my driftfile yields +6.982ppm which I guess is good compared to yours.

Re machine 2 -- I bet your CMOS battery is dying.

> 
> > Having a look at my own machine (a reasonably new Dell laptop) I don't
> > see values quite that bad. I lose about 14 PPM, which amounts to
> > roughly seven minutes in a year.
> > 
> > Having that kind of discrepancies on a network doing distributed
> > development would wreck absolute havoc.
> > 
> > -t
> > 
> 
> 



-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20120704/311f1b74/attachment.asc>