27

In many primers on ntpd, like this one, there's always a warning that ntpd will stop resetting the clock "[if] your clock is too far off."

How far off is "too far off"?

Also, if a server takes a sudden jump to heavy load, for example from total idleness to 100% CPU, will the increase in temperature cause the clock to skew to "too far off"?

Can ntpd be configured to reset the clock even if the time is "too far off" or at least make "too far off" a little farther?

  • `How far off is "too far off"?` Depends. What OS(es)/distros are you you using, specifically? – HopelessN00b Jun 26 '14 at 14:24
  • @HopelessN00b ubuntu server. I figured it'd be hard to pin down because of the algo's complexity, so I can live with a ballpark figure. –  Jun 26 '14 at 14:25
  • All of your questions are variables that you can set in the configuration – Jacob Jun 26 '14 at 14:29
  • @Jacob Thank you Jacob! Would you mind showing me where? I've never seen anything that widens the reset band, and all I can find for higher sync frequency is `burst` which gets you banned. :/ Thank you so much in advance! –  Jun 26 '14 at 14:30
  • I don't think CPU load or temperature should have any effect on your clock. All the timers on a typical computer ultimately come from an oscillator which, as far as I know, is outside the CPU package and not affected by anything the CPU is doing. – Nate Eldredge Jun 26 '14 at 15:29
  • @NateEldredge Probably what I get for devving on a laptop. :/ Will see if this remains an issue on a real server. –  Jun 26 '14 at 16:16

3 Answers3

20

First off, the default max difference is 1000s as others have mentioned. As @kyle stated you can use the -g flag to ignore this ONE time only to initially set your clock.

After that you really shouldn't see your clock drifting by 1000s between updates even under highload, and if you do you really need to replace the clock. The settings in the configuration you need are minpoll and maxpoll. These will allow you to set the interval duration to the power of 2 (e.g. 10 means 210 = 1024 s).

Please note that your system is likely not going to drift substantially even under high load, and the default settings should keep it in check. You don't want to bombard NTP servers with updates every second as you are wasting resources it will get you blocked and most likely a call to your ISP NOC. If you really need extremely accurate time use GPS or setup your own NTP server.

Cristian Ciupitu
  • 6,226
  • 2
  • 41
  • 55
Jacob
  • 9,114
  • 4
  • 44
  • 56
  • 2
    Depending on what you do, the few ms it can drift per day are "substantially" for people. – PlasmaHH Jun 26 '14 at 15:30
  • 2
    @PlasmaHH Then I would suggest utilizing a better time source such as GPS. – Jacob Jun 26 '14 at 15:42
  • Thank you so much Jacob! Do you happen to know what the most common rate limit is? I'd like to maintain good time within the 10ms band shown here http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK without expensive hardware. Thank you very much in advance! –  Jun 26 '14 at 16:26
  • 1
    @Gracchus It's up to the individual NTP servers, and you'd have to contact them. In my opinion you're trying to use NTP as a crutch for something where you need highly precise time. As such you should use a better solution (like GPS) to obtain it rather than add load to a free service. – Jacob Jun 26 '14 at 16:32
  • Replace the clock? What kind of systems have replaceable clocks nowadays? – Gabe Jun 27 '14 at 02:17
  • 3
    @Gabe: Replace here can also mean to add another clock to the system. Also there are quite some options to add various kinds of clocks as pci cards. – PlasmaHH Jun 27 '14 at 08:42
13

NTPD can adjust your clock in slow increments if it's off, clock slewing. The idea behind that is that slow steps won't cause issues with software timers, strange gaps in log files etc.

The maximum slew rate possible is limited to 500 parts-per-million (PPM) by the Unix kernel. As a result, the clock can take 2000s for each second the clock is outside the acceptable range.

According to the manual page ntpd won't work if your clock is more then 1000 seconds off.

Since slewing the clock to adjust it by 1000 seconds will take at least 3 weeks and during that time all date/timestamps are still off, that doesn't seem unreasonable.

The ntpdate command has a -b switch to simply adjust the time without slewing. This is useful in cases where the the local system clock deviates too much from the "correct" time.

HBruijn
  • 72,524
  • 21
  • 127
  • 192
10

This is specified in man ntpd, and you override it you might be interested in the -g option (Note the "which is 1000 s by default":

-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options.

You can adjust this in ntpd.conf. If you want to disable it you can set tinker panic 0. See the Miscellaneous Options documentation to learn more.

Cristian Ciupitu
  • 6,226
  • 2
  • 41
  • 55
Kyle Brandt
  • 82,107
  • 71
  • 302
  • 444
  • Perfect! Finally found `minpoll` and `maxpoll`. Thank you! –  Jun 26 '14 at 14:40
  • Kyle this is wrong. This is a one off command, and will not address future issues. Nor do you mention `minpoll` or `maxpoll`. – Jacob Jun 26 '14 at 14:41
  • 1
    For this to work for me I had to use the following steps 'sudo service ntp stop' 'ntpq -gq' and 'sudo service ntp start' – Terry Horner Feb 09 '18 at 13:53