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? Jun 26, 2014 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.
    – user144330
    Jun 26, 2014 at 14:25
  • All of your questions are variables that you can set in the configuration
    – Jacob
    Jun 26, 2014 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!
    – user144330
    Jun 26, 2014 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. Jun 26, 2014 at 15:29

3 Answers 3


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.

  • 2
    Depending on what you do, the few ms it can drift per day are "substantially" for people.
    – PlasmaHH
    Jun 26, 2014 at 15:30
  • 2
    @PlasmaHH Then I would suggest utilizing a better time source such as GPS.
    – Jacob
    Jun 26, 2014 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 ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK without expensive hardware. Thank you very much in advance!
    – user144330
    Jun 26, 2014 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, 2014 at 16:32
  • 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, 2014 at 8:42

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.


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.

  • Perfect! Finally found minpoll and maxpoll. Thank you!
    – user144330
    Jun 26, 2014 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, 2014 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' Feb 9, 2018 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy