On 2006-07-26, Sergio Ferruchi <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> NTP Public Services Project - http://ntp.isc.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
