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

Tauno Voipio tauno.voipio at iki.fi.NOSPAM.invalid
Tue Jun 14 16:20:47 UTC 2005


Richard B. Gilbert wrote:
> Mark wrote:
> 
>> Colliermeister wrote:
>>
>>> Ulrich Windl wrote:
>>>
>>>> Michael Ward <michaelward at sprintmail.com> writes:
>>>
>>>
>>>
>>>
>>>>> Hello All,
>>>>
>>>>
>>>
>>>
>>>>> 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.


> The problem is not in the hardware but in the software.  The clock we 
> are talking about is the software clock maintained by the O/S.   The 
> hardware divides the crystal oscillator output by a programmable value 
> to produce "ticks" at some predictable rate 100 Hz, 1000 Hz, 1024 Hz or 
> whatever else struck the designer's fancy.  The "ticks" interrupt the 
> processor and the processor takes a couple of microseconds from whatever 
> it's doing to add one tick to the current time.  The O/S disables or 
> masks interrupts for short periods in order to perform some operation 
> that cannot be safely interrupted.  When interrupts are disabled for 
> more than one "tick" the clock loses one or more ticks.
> 
> Most, or all, versions of Windows and Linux exhibit this problem!  Other 
> operating systems; e.g. BSD and Solaris, do not.

It depends.

The newest Linux kernels running with 1 ms (1000 Hz) interrupt rate
can have difficulties keeping up with the clock. The older kernels
with 10 ms (100 Hz) clock work much better.

Part of the problem are clueless device driver writers having
unnecessary interrupt disable regions (often as 'efficiency'
hack). It seems that the IDE/disk driver would need some investigation
in the OP's case.

Turning DMA on disks could (maybe) rescue the situation.

IMHO, ntpd is right in this case - you should not attempt
to NTP sync a sandclock - get a decent timer first.

-- 

Tauno Voipio
tauno voipio (at) iki fi




More information about the questions mailing list