[ntp:questions] Re: ntp sanity limit kills ntp daily

Moe Trin ibuprofin at painkiller.example.tld
Tue Jun 14 19:47:08 UTC 2005

In the Usenet newsgroup comp.os.linux.setup, in article
<d8mkem$na7$1 at aplcore.jhuapl.edu>, Mark wrote:

>>> Michael Ward <michaelward at sprintmail.com> writes:

>>>> I've configured my FC3 system to run ntp successfully at boot time
>>>> and ntp seems to run successfully for about a day.  However, every
>>>> night the clock looses some 1200 seconds while the system is busy
>>>> making backups.   When ntp figures this out, it refuses to update
>>>> the clock because this is classified as insane, and terminates.

>Can someone explain why motherboard companies don't just
>spend an extra $2 and install real quartz based clocks on
>motherboards so all this nonsense about losing time would
>be a non-issue?

First problem - "spend an extra $2"    that translates into roughly a
$20 increase in the consumer price. Ask any manufacturer of consumer goods.

Second problem - the _existing_ hardware clocks have an overall tolerance
(initial setting error, temperature, voltage, and load) of +/- 100 ppm,
which translates to 8.64 seconds per day, or about 4.4 minutes per month.
About a third of this error is the initial setting of the oscillator
frequency. In early PCs, there was an adjustable capacitor to trim this
error. If you bought one, the cost was around US$0.80, - in lots of 10,000,
perhaps half that.   Then you added the cost of time (and test equipment)
to set the adjustment.   You may notice that this capacitor is no longer
installed - it wasn't cost effective.  Temperature effects are _usually_
dominant, and temperature compensating oscillators are several times more
expensive than uncompensated ones.

Third, the "hardware" or "BIOS" clock is normally quite low in frequency
(32768 Hz tuning fork, 1.8432 MHz crystal) to keep power consumption low
(power consumption in CMOS is a direct function of operating frequency).
With most designs, this oscillator is divided internally to 1 Hertz
which is the resolution of that hardware clock.

Fourth, most operating systems keep track of time internally, and this
time is derived from the CPU clock - often running at some spectacular
speed, like 66 MHz or higher.  This frequency is separately divided to
a more usable figure and runs one of the process interrupts (in x86
hardware, IRQ0), and the operating system merely counts the number
of those interrupts to keep track of time.  The advantage of this
design is that the process interrupts provide a much finer granularity
of time - in Linux, this may be 0.01 or 0.001 seconds, depending on
the kernel.

Now, the problem reported by the original poster is actually a mis-behaving
application that is keeping the CPU from keeping up with those process
interrupts.  There are many ways to correct this problem, or at least
alleviate the symptoms, the easiest being to replace the b0rken application.
At the other extreme, simply adding a '/sbin/hwclock --hctosys' command to
the end of the backup script would reset the system clock to something
close to sane.   Replacing either of the existing clock oscillators (BIOS
and CPU clock) with something more accurate would not correct the problem.

        Old guy

More information about the questions mailing list