| View previous topic :: View next topic |
| Author |
Message |
Jon_Hanson
n00b
Joined: 28 May 2002
Posts: 50
|
 Posted: Wed Mar 12, 2003 5:42 pm Post subject: How often does NTP update? |
 |
|
I've installed NTP on all of my systems and they all correctly synchronized to a time server. However, does anyone know how often NTP updates? Here is the output from my /var/log/ntp.log:
| Code: | 27 Feb 09:28:16 ntpd[6522]: ntpd exiting on signal 15
27 Feb 09:34:39 ntpd[6567]: time set 111.071944 s
27 Feb 09:34:39 ntpd[6567]: synchronisation lost
28 Feb 15:31:45 ntpd[6567]: ntpd exiting on signal 15
28 Feb 15:55:56 ntpd[1092]: kernel time discipline status change 41
3 Mar 10:27:52 ntpd[1092]: ntpd exiting on signal 15
3 Mar 10:31:52 ntpd[1070]: kernel time discipline status change 41 |
As you can see NTP hasn't appeared to do anything for more than nine days now and my clocks are starting to drift apart by several minutes. NTP still has a process. My /etc/ntp.drift file seems to be updated at 28 minutes past the hour every hour. I've looked on NTP's web page and there isn't anything helpful there to answer this question.
Also can someone explain the meaning of some of the log entries above? Like why does it say "synchronization lost" immediately after it set the clock? What does "kernel time discilpine status change 41" mean? |
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20583
|
| Posted: Wed Mar 12, 2003 6:58 pm Post subject: |
|
|
Moved from Other Things Gentoo.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
easykill
Apprentice
Joined: 07 Dec 2002
Posts: 230
|
| Posted: Wed Mar 12, 2003 9:06 pm Post subject: |
|
|
i'm not sure what those statements mean, but to get ntp to synchronize every night make a file in /etc/cron.daily called ntp.cron or something, with the following in it
make it executable, and you should be good to go...the clock should synchronize every night for you.
you can substitute the timeserver of your choice for www.clock.org |
|
| Back to top |
|
|
Jon_Hanson
n00b
Joined: 28 May 2002
Posts: 50
|
| Posted: Wed Mar 12, 2003 11:03 pm Post subject: |
|
|
| I think I figured out what the problem was. The DHCP client was stomping my /etc/ntp.conf file wiping out my servers. So I added the -N switch to the DHCP client to prevent that from happening. |
|
| Back to top |
|
|
mr.twemlow
Tux's lil' helper
Joined: 12 Nov 2003
Posts: 90
Location: Illinois
|
|
| Back to top |
|
|
cogitate
n00b
Joined: 05 Dec 2003
Posts: 46
Location: Ontario, Canada
|
| Posted: Fri Apr 16, 2004 3:12 pm Post subject: |
|
|
Just so everyone knows (for anyone else who looks at this), the -N switch on dhcpcd stops /etc/ntp.conf from being overwriten. This is set in /etc/conf.d/net.
| Code: | iface_eth0="dhcp"
dhcpcd_eth0="-R -N"
|
man dhcpcd for more information. (the -R stops /etc/resolv.conf from being clobbered). |
|
| Back to top |
|
|
joeljkp
Guru
Joined: 06 Mar 2004
Posts: 316
Location: Starkville, MS, USA
|
| Posted: Fri Apr 16, 2004 3:21 pm Post subject: |
|
|
| Any word on if this fixes the problem? I've been having trouble with ntpd myself. Namely, it doesn't seem to do anything. |
|
| Back to top |
|
|
ronmon
Veteran
Joined: 15 Apr 2002
Posts: 1043
Location: Key West, FL
|
| Posted: Fri Apr 16, 2004 4:43 pm Post subject: |
|
|
Now that your ntp.conf isn't getting overwritten, you can also set minpoll and maxpoll values to control the frequency of updates. To be a good 'netizen', my router box acts as a stratum3 server for my LAN and gets polled frequently by internal machines. They check external stratum2 servers at less frequent intervals.
| Code: |
server my.router minpoll 4 maxpoll 10 prefer
server stratum2.1.edu minpoll 9 maxpoll 15
server stratum2.2.edu minpoll 9 maxpoll 15
|
It will start with the minpoll interval and gradually lengthen as confidence increases.
_________________
Ask Questions the Smart Way - by ESR |
|
| Back to top |
|
|
tam1138
Tux's lil' helper
Joined: 28 Oct 2003
Posts: 103
|
| Posted: Fri Apr 16, 2004 7:46 pm Post subject: |
|
|
A good command for checking ntp health is "ntpq -p". That is, query ntp for information about its peers. (Add a hostname afterwards to query another machine.) Here is some example output:
| Code: | tam@beleriand:~ $ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 59 64 377 0.000 0.000 0.000
+clepsydra.dec.c .GPS. 1 u 506 1024 377 25.707 -17.163 0.867
+ntp-cup.externa .GPS. 1 u 222 1024 373 42.874 -10.238 10.695
*usno.pa-x.dec.c .USNO. 1 u 243 1024 377 30.181 -14.609 23.441
gondolin.hidden beleriand.hidde 3 u 18 128 377 0.369 0.064 0.008
rivendell.hidde beleriand.hidde 16 u 12 1024 0 0.000 0.000 4000.00 |
The first line is for the local clock that is only used in case others are not available (depending upon your config, I believe, I'm pretty sure this is the default behavior). The "when" column denotes the number of seconds since that peer was last heard from. The "poll" column denotes the polling interval in seconds. (When the value in the "when" column reaches that of the "poll" column, the local machine will ping the peer, the server will respond, and the "when" will be reset to 0.) Delay denotes latency between the local machine and the peer. Offset denotes how much the local clock differs from that of the peer. Jitter is a little tricker; read some man pages to figure it out.
You'll note that one of the peers has a "*" next to it; this means that it is the system peer (for now). The other two peers with "+" signs are candidates to become the system peer. Two machines have no marking because they were removed from the peer-selection group for whatever reason. (In this case, likely because they have a high stratum -- the "st" column.) Lastly, the refid column denotes the system peer of that peer. So in the output above, clepsydra.dec.com is attached directly to a GPS clock, whereas gondolin and rivendell think beleriand's time is king.
There is a lot more info in the manpages for ntpd(1) and ntpq(1). |
|
| Back to top |
|
|
kezzla
Apprentice
Joined: 21 Aug 2003
Posts: 253
Location: Austin, TX
|
| Posted: Tue May 11, 2004 11:40 pm Post subject: |
|
|
The ntp update algorithm is dynamic  The more the time is off the more often it updates....
The poll interval is determined by a shift register in a variable in
the ntp code. It is either a 32- or 16-bit value (I forget which),
with a single bit set at any time. The value for this register holds
the number of seconds until that clock is polled. For example, if
the register value is 16 (010000b), the clock will be polled at 16
second intervals. At various times during operation, this bit may
be shifted either left or right, effectively doubling or halving the
time between subsequent polls.
Basically, if a poll is made and the clock is found to be
sufficiently close, the bit is left shifted. If the clock is
found to be sufficiently out of sync, the bit is right shifted.
This allows ntp to minimize traffic when systems stay close of
their own accord, but also maximize accuracy when clocks are
drifting at a faster rate.
So, it is not uncommon to see a client polling several times a minute
one day (usually shortly after startup or some time shift event),
but poll at a much slower rate the next.
The rate should never be on the order of once every few days,
however.
As for the sync lost messages, these are usually due to lost
reachability to the system peer (i.e. lost packets or no server
response). Unfortunately, NTP is designed to use UDP, which is
unreliable (in the sense of ACKs and sequence control), and so is
prone to the occasional lost or out of order packet.
As long as the sync is established fairly quickly (i.e. a small
multiple of the drift rate), the quality of time will not be
badly compromised. (There may be a separate network stability
issue, though...even UDP shouldn't lose _too_ many packets.) |
|
| Back to top |
|
|
|
Networking & Security
