[arch-general] Leap seconds ntp and chrony?

Leonid Isaev lisaev at umail.iu.edu
Wed Jul 4 14:23:23 EDT 2012

On Wed, 4 Jul 2012 16:42:04 +0100
Kevin Chadwick <ma1l1ists at yahoo.co.uk> wrote:

> > > What I mean by similar to is if it doesn't benefit you,
> > > you will have less bugs and a more stable and secure system by reducing
> > > code usage.  
> > 
> > Are you just saying that people who don't need an NTP daemon are better
> > off not running one?
> Yep and many who think they do need one may well not need one. I
> think stories of RTC inaccuracy are exaggerated due to those who really
> need very accurate clocks and so getting rather annoyed. PC hardware is
> designed with just it's RTC and no ntp in mind after all.

But the goal of ntp is not only timekeeping, but mainly syncronization.
Potentially everyone needs precise timesync, unless you exist in a lab
isolated from the world. For example, kerberos 5 needs time syncronization
between clients and a server. I can imagine that dhcp leases do too,
especially on busy networks like those deployed in universities. 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...

> Some distros like Ubuntu seem to assume (or did) that no one would ever
> want to switch ntp off. I wonder if any ubuntu server users have had any
> issues there recently. I guess they wouldn't have known until it was
> too late though?

That is a reasonable assumption (windows vista/7 makes it too, btw). The only
downside may be CPU wakeups caused by ntp, but that's the chrony story.
Regarding ubuntu servers and leap seconds, they were not any more or less
vulnerable than others. Whether or not you were affected depended on
particular applications which were run atm. For example, on my machine leap
second addition was completely seemless.

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/8d1f5f42/attachment.asc>

More information about the arch-general mailing list