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

Sergio Ferruchi holger.koch at mails.de
Wed Jul 26 13:34:27 UTC 2006


Hello,

as I know there are a lot of issues according high NTP drift values and
time resets.
Nevertheless I need some help according my specific NTP configuration
problem.

I have a multi blade shelf where I try to synchronize the time on each
blade according one reliable time reference.

Lets say two blades are connected to the outside world and can
theoretical reach external NTP servers. Other blades behind are only
able to get the time from the 2 servers.
Because I dont know which one is up and running I configured just both
NTP servers fro the blades behind.

The NTP servers which reach external NTP servers do peer each other to
beeing able to synchronize each other if one server can not reach the
external server but the partner server.
Additionally I want the other blades synchronizing their time to the
front servers even if these servers do not have a valid external time
signal. Therefore following configuration apply for the front servers:

     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
 127.127.1.0     LOCAL(0)        11 l   10   64  377    0.000    0.000
 0.001
+10.168.105.52   192.168.130.172  4 u  134  256  376    0.215   -1.613
 0.231
*192.168.130.172 139.21.3.139     3 u   80  256  377    0.204   -1.643
 0.125
+192.168.130.173 139.21.3.139     3 u   24  256  377    0.174   -1.309
 0.090
-192.168.130.178 139.21.3.139     3 u   29  256  377    0.196   -0.683
 0.087


The other front server has a similar configuration:

     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
 127.127.1.0     LOCAL(0)        12 l   14   64  377    0.000    0.000
 0.001
-10.168.105.60   192.168.130.172  4 u  156  256  377    0.136    1.909
 0.249
*192.168.130.172 139.21.3.139     3 u  440 1024  377    0.255    0.364
 0.530
+192.168.130.173 139.21.3.139     3 u  313 1024  377    0.195    0.632
 0.425
+192.168.130.178 139.21.3.139     3 u  424 1024  377    0.219    1.249
 0.659


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

I know to have 2 servers is not really optimal but I need the
redundancy for the servers behind the front servers and I know to
configure a shared ip is not allowed because it can confuse ntp
seriously.

Additionally I observed time resets

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

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


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.
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?

Thank you for your answers.




More information about the questions mailing list