[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