[ntp:questions] High NTP drift values, time resets and hwclock command

Danny Mayer mayer at ntp.isc.org
Thu Jul 27 02:07:20 UTC 2006


Sergio Ferruchi wrote:
> My ntp.conf file of the front server looks as follows:
> 
> restrict default ignore
> tinker panic 0
> restrict 127.0.0.1
> # allow access from dependent blades via internal ip addresses
> restrict 10.168.105.0 mask 255.255.248.0 nomodify notrap
> server  127.127.1.0
> fudge  127.127.1.0 stratum 11
> driftfile /etc/ntp.drift
> broadcastdelay  0.008
> peer 10.168.105.52
> restrict 10.168.105.52
> server 192.168.130.172 prefer iburst
> restrict 192.168.130.172 nomodify
> server 192.168.130.173 iburst
> restrict 192.168.130.173 nomodify
> server 192.168.130.178 iburst
> restrict 192.168.130.178 nomodify
> 
> 
> and for the servers behind
> restrict default ignore
> tinker panic 0
> restrict 127.0.0.1
> server  10.168.105.60 iburst
> restrict  10.168.105.60 nomodify
> server  10.168.105.52 iburst
> restrict  10.168.105.52 nomodify
> driftfile /etc/ntp.drift
> broadcastdelay  0.008
> 


Lose all restrict statements. You can add them back in when you have
things workintg to your satisfaction and when you understand what each
one is doing.

Why do you have broadcastdelay specified? You didn't configure a
broadcast client so what's it for? Why are you using tinker panic 0
instead of using the -g option in the startup?

> 
> So can anybody tell me whether the configuration still contains NTP do
> nots, because I have sometimes throubles with high ntp drift values.
> Maybe the local clock is bad.

You need to start with a simple ntp.conf file and then add complexity
only if you really need it. In your case you are using private addresses
so you really don't need to bother with restrict statements in the first
place unless you cannot trust other people in your local network in
which case you have a social/HR problem rather than a technical one.

> Additionally I use a hwclock -systohc command every 10 minutes by a
> cron job to update the hwclock periodically to be able to have a valid
> hardware clock in case of the blade is not shutdown properly and
> shutdown script is not executed at all. Could it be that hwclock call
> can confuse the NTP protocol?
> 

Never do this. You need to leave it to NTP to control the clock. It
knows better what it's doing. It may very well be the main cause of your
problems. Who advised you to do this?

Danny



More information about the questions mailing list