[arch-general] Leap seconds ntp and chrony?

[Leonid Isaev]

On Tue, 03 Jul 2012 14:10:55 +0100
Mauro Santos <registo.mailling at gmail.com> wrote:

> On 03-07-2012 12:07, Kevin Chadwick wrote:
> >>  it sure isn't for consumer hardware.
> > 
> > They could use better use of crystals in the main like watches but I
> > think they are good enough for all except corner cases. One guy on the
> > android list said research had come out with an average of two second
> > slide sqew per week or something rediculous and which I don't believe
> > for one second. I'll start my own tests sometime and find out, including
> > software slide. Either way NTP is irrelevent to me, my servers seem in
> > sync too. So I'd still say the best solution for most purposes is not
> > to use NTP at all.
> > 
> 
> The problem is that the crystal isn't the only thing that affects the
> stability of a clock. Without looking at it in-depth I would dare say
> that the crystal is what contributes less to instabilities. I would say
> that temperature and voltage dependencies, manufacturing process
> variations and noise immunity in the RTC electronics might account for
> more variation than the variation that comes from the crystals.
> 
> Better electronics and means a more complex circuit thus more silicon
> area and cost per chip, a more complex circuit probably means more power
> usage thus it will drain backup batteries or capacitors faster, so
> unless there is a strong requirement for it there is no incentive to use
> really circuits with an higher accuracy or better drift characteristics
> or to provide good supply voltage filtering and implement EMI shielding,
> all these things add to cost and the area/volume required on the PCB.
> 
> For most usages the RTC is accurate enough, when more precision is
> desired you either source parts that specifically comply with your
> requirements or you can always use some ntp client to sync from a time
> server, you most probably have to use some ntp client to sync from a
> time server when you have more than one machine running and want to have
> consistent time stamps between machines.

RTC was never designed to be precise. These days OS kernels use ~ 10
nanosecond resolution, so RTC are not fit for the job simply because they run
from battery which looses charge over time. A proper use for RTC is as a
reference point to start off your kernel time.

Besides, most modern devices (routers, cable modems, ARM/MIPS-based PC) do not
even have an RTC -- they start from Jan 1 1970 and then sync clock over web.

> 
> Like everything else ntpd has to be properly secured and configured, if
> properly done I suppose it isn't a bigger security problem than anything
> else with network access. This problem about the leap second and
> programs going awry is due to a bug in the kernel and not a problem with
> ntp itself, the only fault that can be attributed to ntp is to expose
> that bug.
> 

Exactly. Also, ntp doesn't even use TCP -- all ports involved are UDP.

-- 
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/20120703/fc367a28/attachment.asc>