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

Steve Kostecke kostecke at ntp.isc.org
Thu Jul 27 03:37:00 UTC 2006


On 2006-07-26, Sergio Ferruchi <holger.koch at mails.de> wrote:

> The server behind the front server all have following configuration:
> remote         refid          st t when poll reach delay  offset jitter
>========================================================================
> *10.168.105.60 192.168.130.172 4 u  150  256 377   0.122  25.306 17.234
> +10.168.105.52 192.168.130.172 4 u  160  256 377   0.109  32.352 23.496

This is only a snapshot of the current peer stats. You need to watch
this over time to see how it changes.

I'd be a bit concerned about a 25ms offset to a time server in the same
rack.

> Jul 26 12:16:41 sb1-1 ntpd[10225]: time reset +0.481624 s
> Jul 26 12:18:00 sb1-1 ntpd[10225]: synchronized to 192.168.130.172,
> stratum 3
> Jul 26 12:36:16 sb1-1 ntpd[10225]: time reset -0.197015 s
> Jul 26 12:37:35 sb1-1 ntpd[10225]: synchronized to 192.168.130.172,
> stratum 3
> Jul 26 13:07:42 sb1-1 ntpd[10225]: time reset +0.263151 s
> Jul 26 13:09:02 sb1-1 ntpd[10225]: synchronized to 192.168.130.172,
> stratum 3

This means that 'sb1-1' has drifted more than the default step threshold
(128ms). Does this occur only on the "clients" or the "servers"?

If the resets (steps, actually) were always in the same direction and of
roughly the same magnitude it could be a matter of a tick adjustment.
But since the steps are divergent it's likely something else.

What OS / (kernel) version are you running? Does the hardware have any
sort of power-management, variable processor speed, etc. ?

> My ntp.conf file of the front server looks as follows:

aka "servers"

> driftfile /etc/ntp.drift

Some people feel that daemons have no business writing to /etc and
should use /var. But this is not a problem.

> broadcastdelay  0.008

Unneeded but not a problem.

> tinker panic 0

This command modifies the ntpd panic threshold (which is normally 1024
seconds). Setting this to 0 disables the panic sanity check and a clock
offset of any value will be accepted.

Why do you feel you need this?

> server  127.127.1.0
> fudge   127.127.1.0 stratum 11

You've correctly fudged the LocalCLK to a reasonable stratum. You may
wish to fudge the LocalCLK on the two (front) servers to different
strata (i.e. one to 11 and the other to 12) so that the clients will
follow one of the (front) servers.

> restrict default ignore
> 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

OK. You may wish to review the explanation of 'nomodify' at
http://ntp.isc.org/Support/AccessRestrictions.

> peer 10.168.105.52
> restrict 10.168.105.52

OK

> 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

OK

> and for the servers behind

aka "clients"

> driftfile /etc/ntp.drift
> broadcastdelay  0.008
> tinker panic 0

See my comments above.

> restrict default ignore
> 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

OK

-- 
Steve Kostecke <kostecke at ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/




More information about the questions mailing list