- Red Hat Enterprise Linux 4
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- What to do if
frequency error -3017 PPM exceeds tolerance 500 PPMoutput like below?
host1 ntpd[xxxx]: frequency error -506 PPM exceeds tolerance 500 PPM
host1 ntpd[xxxx]: frequency error -512 PPM exceeds tolerance 500 PPM
host1 ntpd[xxxx]: frequency error -590 PPM exceeds tolerance 500 PPM
host1 ntpd[xxxx]: frequency error -553 PPM exceeds tolerance 500 PPM
Adjusting the time with
As a first approach to solve the issue, the
ntpdservice should be stopped and the time be adjusted manually with the
This will only fix situations where the offset between ntpd computed time and internal clock is big, but the internal clock is working reasonably accurate (so can be compensated by
# service ntpd stop
# ntpd -qg
# service ntpd start
- Information about the above options from man page :-
Normally, ntpd exits if the offset exceeds the sanity limit, which is 1000 s by default. If the sanity limit is set to zero, no sanity checking is performed and any offset is acceptable. This option overrides the limit and allows the time to be set to any value without restriction; however, this can happen only once. After that, ntpd will exit if the limit is exceeded.
Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option.
Using a different timesource
RHEL5 and RHEL6 allow changing of timesources, on RHEL6 this is possible on the fly(without reboot the system).
The timesource can be changed, different timesources could be more reliable in the system.
Please refer to How to change the clock source in the system? for more details.
- For Virtual Machines, add following at the top of /etc/ntp.conf
tinker panic 0
The time computed by ntpd and the one reported by the systems internal clock exceeds 500 PPM would lead to the observed log messages. If the difference exceeds 500 parts-per-million (0.0005) over the synchronization interval then the log message appears.
Several root causes are possible for example, incorrectly working timesources in the system.
Further steps to debug the issue:
If multiple systems are affected by the issue:
- Do affected and not affected systems use a common NTP server as source?
- Are there differences in hardware versions or types between the servers?
- Have all affected systems the same kernel and ntp packages installed?
Has a hardware issue been ruled out in replacing the clock of the system? This might involve changing the motherboard.
- On RHEL5 the command
adjtimex, on RHEL6 and RHEL7
tickadjcould be used to change the kernel tick rate. This might be useful in cases where the hardware clock has been identified as being the root cause.
- Red Hat Enterprise Linux
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.