hwclock can cause system lockup

Todd Denniston Todd.Denniston at ssa.crane.navy.mil
Fri Oct 17 21:42:49 UTC 2008


Ian Burrell wrote, On 10/17/2008 02:40 PM:
> Todd Denniston <Todd.Denniston <at> ssa.crane.navy.mil> writes:
>> 1) you don't need to call hwclock while NTP is running to keep the hardware 
>> clock synced to system time, the kernel hackers "helpfully" put a sneak 
>> circuit in the ntp implementation in the _kernel_ such that if NTP declares a 
>> good sync with the external source, then the kernel will every 11 minutes 
>> write the system time to the hardware clock.
>> 2) (1) messes up /etc/adjtime in two ways
>> 	a) the bios time has been set independent of the hwclock use of /etc/adjtime, 
>> so the time since last set is wrong.
>> 	b) because of (a) the amount the clock needs adjusted for drift each time 
>> hwclock --adjust is called is now wrong.
>>
>> You can kind of work around the problem by having your script that calls 
>> hwclock -systohc monitor either the adjtime drift or ntp's connectedness to a 
>> real server and keep the drift the same while ntp has sync, i.e, have the 
>> script keep the original adjtime drift if either the call is being made when 
>> ntp is known to be synced or the drift changes too much towards 0.
>>
>> I have toyed with the idea of trimming that out* of my kernels, but it would 
>> mean a recompile every time a kernel update happened.
>>
>> *or at least making it some kind of boot configurable item, and try to get 
>> that patch in the kernel tree.
>>
> 
> Why don't you just use the ntpd local clock driver?  The Fedora /etc/ntp.conf
> has the following lines commented out:
> 
> #server 127.127.1.0     # local clock
> #fudge  127.127.1.0 stratum 10  
> 
> Uncommenting those causes ntpd to use the local hardware clock as a backup time
> source.  ntpd will keep track of the drift and record it in the drift file to
> use when starting.  It should keep fairly accurate time as long as it
> occasionally is connected to the network.
> 
>  - Ian
> 
> 
1) because in Chris's case you are not using ntp on the machine in question to 
get time from elsewhere, there is no elsewhere, i.e., no network.  This is not 
a `fall back while still disciplined to the local clock`, this is a `we will 
never see a _true_ stratum (ntp referenced from a reference clock) anything at 
this physical location`.

2) Because the BIOS clock can be looked at under certain circumstances (such 
as a box running 24X7X365) as slightly ovenized* and independent of processor 
and IO load.

ntpd local clock is subjected to changes due to system processor load and IO 
load, i.e., missed interrupts.


*in an air conditioned office space, an on-all-the-time machine should have 
temp fluctuations of less than 10F day to day. each day you might see a swing 
that is 30F in that day, but when each day is compared the temps at the same 
time of the day is much closer, and hwclock does not calculate new drifts in 
time spans of less than 1 day.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter




More information about the fedora-list mailing list