[arch-general] Leap seconds ntp and chrony?

Mauro Santos registo.mailling at gmail.com
Tue Jul 3 09:10:55 EDT 2012

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.

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.

Mauro Santos

More information about the arch-general mailing list