2

Neither the openntpd nor the ntpd.conf manpage have this information.

John Bachir
  • 2,344
  • 7
  • 29
  • 37

2 Answers2

5

Time updating happens on a continuous basis. The daemon keeps track of how the time-rate of the hardware clock drifts from the time reported by the upstream sources. It polls the upstream sources based on an algorithm and can change. The actual poll-rate is a power-of-two in seconds. You can query this information through the ntpq command.

Different time daemons have different defaults for what it'll allow the maximum poll time to be. I've seen it go as long as a couple of days between polls of upstream servers, and others where it never goes past about 20 minutes. The minpoll and maxpoll values on your server lines in the ntpd.conf file itself will provide, if set, the exact power-of-two for that upstream server.

Upstream polling is used to determine how to modify the drift rate. It is very important for the NTP daemon to not hard-set time, instead it just increases the length of a second by a tiny amount for a while until the local time converges with the time reported by the upstream time servers.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
4

NTPd is always actively adjusting the time. It works by speeding up the length of a second or slowing it down to bring the time into sync gradually. A sudden change in time can be problematic for many services / daemons. It's widely considered better practice to correct it this way. If you are sure you won't be affected and need a quick sync for a clock that's way off, stop the ntpd service and use the ntpdate command.

Aaron Copley
  • 12,345
  • 5
  • 46
  • 67
  • 4
    +1 Stopping ntpd isn't necessary to use `ntpdate -u pool.ntp.org` though. The process by which it updates the clock is called slewing the clock (as Aaron described). Ntpd checks with its configured time servers on a regular basis, usually between 64 and 1024 seconds (by default) depending on the stability of the local and remote clocks. – Chris S Jan 17 '11 at 21:01
  • Oh nice, the `-u` sends it out an unprivileged port which gets around the socket in use error... Didn't know about that! – Aaron Copley Jan 17 '11 at 21:05