# How often does NTP update?

## Jon_Hanson

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:

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

----------

## pjp

Moved from Other Things Gentoo.

----------

## easykill

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

```

#!/bin/sh

/usr/bin/ntpdate www.clock.org

```

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

----------

## Jon_Hanson

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.

----------

## mr.twemlow

I think I need to do the same thing.  Where exactly do you add the -N switch?  I've lost myself.

----------

## cogitate

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.

```
iface_eth0="dhcp"

dhcpcd_eth0="-R -N"

```

man dhcpcd for more information. (the -R stops /etc/resolv.conf from being clobbered).

----------

## joeljkp

Any word on if this fixes the problem? I've been having trouble with ntpd myself. Namely, it doesn't seem to do anything.

----------

## ronmon

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.

```

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.

----------

## tam1138

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:

```
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).

----------

## kezzla

The ntp update algorithm is dynamic  :Wink:  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.)

----------

