Содержание
- ntpd не синхронизируется и не по нему не синхронизнешься
- Re: ntpd не синхронизируется и не по нему не синхронизнешься
- Re: ntpd не синхронизируется и не по нему не синхронизнешься
- Re: ntpd не синхронизируется и не по нему не синхронизнешься
- Re: ntpd не синхронизируется и не по нему не синхронизнешься
- Re: ntpd не синхронизируется и не по нему не синхронизнешься
- Re: ntpd не синхронизируется и не по нему не синхронизнешься
- Why does ntpd error message » ntpd[xxxx]: frequency error -512 PPM exceeds tolerance 500 PPM » displayed in /var/log/messages?
- Environment
- Issue
- Resolution
- Adjusting the time with ntpd -qg
- Using a different timesource
- Root Cause
- Diagnostic Steps
- Frequency error 500 ppm exceeds tolerance 500 ppm
ntpd не синхронизируется и не по нему не синхронизнешься
Re: ntpd не синхронизируется и не по нему не синхронизнешься
udp 123 порт в firewall открыл?
Re: ntpd не синхронизируется и не по нему не синхронизнешься
Я его и не закрывал. Кроме того, ntpdate работает ведь. Оно ж на тот же порт вешается, что и ntpd.
Аналогичная фигня на другом сервере (совсем без фаерволов, на очень приличном канале — я у себя на пинг пенял, но там пинг — на высоте). Конфиг там — идентичный.
Re: ntpd не синхронизируется и не по нему не синхронизнешься
Попробуй убрать все restrict опции. ИМХО они могут быть записаны только в виде ip-адресов, а не DNS имен.
Re: ntpd не синхронизируется и не по нему не синхронизнешься
а может быть у него еще пока не тот stratum?
Re: ntpd не синхронизируется и не по нему не синхронизнешься
Это «пока» длится не первые сутки. Да и сам себе он не правит часы..
ща попробую сделать синхронизацию по IP, а не доменам
Re: ntpd не синхронизируется и не по нему не синхронизнешься
Поделитесь рабочим конфигом, плз. С статическими IP-адресами вроде начало синхронизироваться:
22 Feb 16:07:47 ntpd[21774]: frequency error -512 PPM exceeds tolerance 500 PPM 22 Feb 16:25:11 ntpd[21774]: time reset +0.351048 s 22 Feb 16:34:45 ntpd[21774]: synchronized to 62.4.94.211, stratum=2 22 Feb 16:46:35 ntpd[21774]: time reset +0.159243 s 22 Feb 16:56:14 ntpd[21774]: synchronized to 62.4.94.211, stratum=2 22 Feb 17:47:42 ntpd[21774]: synchronized to 202.49.159.9, stratum=2 22 Feb 17:59:45 ntpd[21774]: no servers reachable 22 Feb 18:01:37 ntpd[21774]: synchronized to 212.23.29.225, stratum=3 22 Feb 18:10:30 ntpd[21774]: synchronized to 202.49.159.9, stratum=2 22 Feb 18:29:41 ntpd[21774]: no servers reachable
но потом снова в логах полная тишина. При попытке синхронизации по этому серверу старая история — stratum 0
Источник
Why does ntpd error message » ntpd[xxxx]: frequency error -512 PPM exceeds tolerance 500 PPM » displayed in /var/log/messages?
Environment
- Red Hat Enterprise Linux 4
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- ntpd
Issue
- What to do if ntpd logs frequency error -3017 PPM exceeds tolerance 500 PPM output like below?
Resolution
Adjusting the time with ntpd -qg
As a first approach to solve the issue, the ntpd service should be stopped and the time be adjusted manually with the -qg option.
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 ntpd ):
- Information about the above options from man page :-
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.
Root Cause
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.
Diagnostic Steps
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.
- Product(s)
- Red Hat Enterprise Linux
- Component
- ntp
- Category
- Troubleshoot
- Tags
- rhel
- rhel_4
- rhel_5
- rhel_6
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.
Источник
Frequency error 500 ppm exceeds tolerance 500 ppm
posted 02-21-2014 09:23 PM 
I recently started working in the projection booth at a local 16-plex and I was shocked to find staff manually starting shows due to a drifting clock, that would drift a minute or so a day unless the show server was reset Now, I don’t have a whole lot of projection or even job based IT experience, but I do have (what I would like to think) a head placed firmly on my shoulders and thankfully, some linux experience.
Configuration Information
- DSL100 TMS
- 16 Auditoriums, 14 running a DSS220/CP650/NA10 setup with a CP2230 Projector
- 2 running a DSS200/CP850/NA10 setup with a CP2230 Projector
- Server Software: 4.6.1.4
After fixing some blatant software misconfiguration issues
- DSL100 TMS configured for a non-existent NTP server
- Auditoriums configured to access external NTP servers they couldn’t access due to firewall
- IMB clocks that were off
Things are running much better, the theatre clock in the show manager always displays the correct time but the automatic starts (though much more reliable than they were) are still off, the main difference now being that a restart of the auditorium’s screen server fixes it, but only for a couple days or so. Some auditoriums are worse than others in this regard.
checking /status/log/ntp.log directly yields the most interesting info
quote: timestamp ntpd[####] synchronized to 192.168.241.2, Stratum 2
timestamp ntpd[####] Frequency Error 502 PPM exceeds tolerance 500 PPM
1h30m after start.
Looking this up, I can see that it basically means the local clock is too inaccurate for the ntp update to take, which unfortunately is why I need the ntp in the first place! Some of the non d-cinema sources I found discussing the problem state the error could be indicative of an issue with the clock hardware, which I find somewhat difficult to believe considering the same error occurs in all 16 auditoriums.
Checking the logs in the ShowManager GUI for the NA10, I see another interesting but potentially irrelevant line
Thread RealTimeSync: ntp: unable to bind to socket
| David Buckley Jedi Master Film Handler Posts: 525 |
posted 02-21-2014 09:49 PM  General advice on running ntp, I am currently cinema-less and yet to join the digital revolution.
Lets start with ntpq -p on the TMS and on a couple of the DSSs. Can’t bind to socket could be very bad; see what is bound to the socket by doing netstat -ap |grep ntp The way you should have a network full of boxes configured for time is just one machine is the time master, and it syncs with external clocks, and then all your internal machines should just point to that one server. The way this is configured is the server keyword in /etc/ntp.conf. |
| Tim Hillstromb Film Handler |
posted 02-21-2014 10:50 PM Thank you for the response David The way I understand, dolby system software is designed to not allow me to enter those commands without root privileges, and according to this forum there is no way to legitimately obtain said privilege. The account I am using has been given permission to execute pre-supplied scripts in the home directory, use cat or less to display a subset of the system logs, and ssh into the other networked boxes and do the same. I cannot even see the part of the filesystem the ntpd binary is on. When I was troubleshooting the issue initially I configured all of the servers to contact the TMS for time, and the TMS to contact external server for time. Looking at the logs, it seems that the connection is being made at least once each start, but only the TMS has been keeping time. The DSSes are drifting as much as 5min in 4 days (usually less). |
| David Buckley Jedi Master Film Handler Posts: 525 |
posted 02-21-2014 11:35 PM That is indeed unfortunate; its rather hard to diagnose NTP driftiness (and many other problems!) with ones hands tied behind ones back. Sounds like you may be in a chroot jail.
As a longshot, one could try ntpq -p [ip_address_of_server] from a random «proper» linux box, or perhaps a Windows machine booted onto a linux live CD. Though its probable that the servers have been locked down to prevent this kind of remote query. Properly configured NTP is not supposed to «set and forget», though many machines, particularly of the Windows variety, behave that way; ntp is supposed to keep the clocks syncronised together continuously by making tiny adjustments and comparing machine time to reference(s). As a passing observation, the fact that sixteen machines agree the time and one doesn’t could point to an issue with the TMS timekeeping. Alternatively, the Dolby software may cause the playback machine timekeeping to go wonky through the demands it makes on the hardware. |
| Steve Guttag We forgot the crackers Gromit. |
posted 02-22-2014 06:29 AM I have a bit of experience here.
First. get the local clocks on all servers as accurate as you can WITHOUT any NTP reference. this means disconnecting the «Theatre Network» cable (no need to configure the NTP out in the config script). Since you are using the DSL100 as your local NTP reference, that is the first thing that needs to be made accurate. Dolby has always used the BIOS clock as its «Show Clock» so to get it accurate without an NTP reference, reboot the sever and on boot up, press (repeatedly) the key until you get the BIOS screen. The clock will be in UTC time so you should only need to work with the minutes and seconds. again. get this as accurate as possible. out and let the DSL100 boot up fully. Then reboot it with NTP connected. during the boot up you should see when it connects to NTP and notes the offset to be applied. hopefully, it is less than a second out. The DSL100 clock (as was the DSS100 and DSP100) were pretty accurate on their own. The same cannot be said of the DSS200 clocks. they are all over the place. The CAT745 clock shouldn’t even be called a clock. sundials are more accurate than that. For each server. again, disconnect the Theatre Network, and reboot the server. let it come up fully off network. Set the secure clock in the GUI (projector must be on). Try to get it as accurate as you can. On the CAT745s, it may have drifted fast (always fast) to the point it can’t be set. if so, there is a CLI command that will let you adjust its range to something usable again. You’ll need CLI administrator privileges to use it. Do an «ls» and the script will be apparent and will provide instructions. Once the secure clock is set. Reboot it up fully. Now set the BIOS clock as was done with the DSL100 (again everything off of NTP) and let it boot up fully. Once you see everything on time in the GUI it is time to reboot it but with NTP connected. Presuming you have good NTP, within an hour or two, the servers should acknowledge good NTP (NTP Configured and NTP Connected should read the same IP address on all devices). But wait. there is more! Update ALL systems to System 4.7.1 (10). this is VERY important. Aside from the other issues that exist in Systems 4.5 and 4.6 that 4.7 actually fixes, Dolby has dramatically improved the NTP function. It will poll NTP at double the rate to catch NTP drift and not let it get out of range. Only those BIOS clocks that are too hopeless will fall out of range and that is a case for a warranty replacement of the defective server (if they are still in the warranty period). Once on System 4.7, periodically, particularly in the first couple of weeks, reboot the servers and library. System 4.7 will apply a clock drift offset (you can see this on the boot up. And, of course, make sure your NTP source is steady. Dolby is a bit strict on NTP protocol. If the NTP source disappears for a small amount of time and the DSL100 doesn’t get its update. you’ll see EVERY sever complain about NTP issues and it will take a couple of hours of good NTP to calm them down. Since you say it is calling the DSL100 Stratum 2. I’m guessing you are having the DSL100 call out, directly to some master NTP source like NIST. I’ve found that to be less than reliable (not NIST but calling, directly out to a Stratum 1). They seem to get bombarded by everybody and every once in a while, when NTP is checked. it can’t connect and you get the NTP connection warnings. I generally go for one Stratum down from a 1. Often that is as easy as having a PC on site talk to a site like NIST or use the ntp pool (and a pc can use a DNS to work with the ntp pool). though you’ll need to set up the PC to act as an NTP source and then have the DSL reference that clock. You’ll then never see the NTP errors. everything will stay in good sync too. Naturally, you can also purchase an actual NTP source for the site. but that is typically more expensive and one has to set up antennas and such. So, to refresh. Disconnect the Theatre Network. get both the secure clock and the BIOS clock set as accurately as possible and allow to boot up fully. Connect up a GOOD NTP source and reboot everything with that. Get to System 4.7 ASAP. In fact, it would probably be better to move to System 4.7 first. Oh, and once on System 4.7, those CAT745 HDMI ports will also work. I also normally make sure that the ICP clock, projector clock and Enigma clock (if present), are also as accurate as possible. thus when looking at logs, everything lines up. Note, Christie uses the IMB clock as its clock so you’ll see drift on your Christie TPCs as the CAT745 drifts. and it will and it doesn’t use NTP though I wish it did. or at least reference the BIOS clock once it is set right). |
| David Buckley Jedi Master Film Handler Posts: 525 |
posted 02-22-2014 01:54 PM Flipping heck!
I must need a new set of glasses. I’m sure that says «Dolby has made the broken NTP implementation broken in a little different way». Implemented correctly, NTP is really clever, and self-manages how often it needs to poll other time sources. Steve’s advice to have an on site NTP server is good though, and even more so if the servers are «picky». Go out and buy a raspberry pi plus case plus SD card combo, a USB power supply and cable, (all up well under a hundred bucks) peer it with two or three GPS clocks, hide it in a corner and forget it exists. Here how my local timesource is performing:
This illustrates I’m synced with three stratum 1 GPS clocks (two in New Zealand, one in the USA), NTP has chosen to poll them once every 1024 seconds (it starts off at 64 seconds, and then adjusts as NTP gains confidence in the realative timekeeping of the local host and the external sources), and all the times for delay, offset and jitter are in milliseconds. The asterisk is the chosen upstream clock source, and the plus signs show that NTP believes these other sources are also acceptable. This is pretty typical NTP, with the time on this host within milliseconds of perfection. |
| Steve Guttag We forgot the crackers Gromit. |
posted 02-22-2014 03:00 PM It is my belief that the BIOS clocks used in the servers are so wild that NTP has a tough time keeping them in line. The server will show that one has a good NTP source and the clock will drift anyway («exceeds 500ppm»). To ensure a constant time-line, the clock can only be slewed to correct time (except, seemingly, at boot up). |
| David Buckley Jedi Master Film Handler Posts: 525 |
posted 02-22-2014 03:41 PM BIOS clocks can be problematic; I have an old PC in the garage that uploads weather data to the interwebs, and it has a knackered BIOS clock; it gets synced to network time every five minutes to try and keep it in line, and even so its gaining (average) about 5 seconds every 5 minutes!
But this is a many old machine, and its running Windows, and I run a third party NTP client on it. This third party client is not proper NTP by any means, just grab and set. All times are Central (GMT -6:00) The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion and agrees to release the authors from any and all liability. Источник Adblock |
Printer-friendly view of this topic Environment
- Red Hat Enterprise Linux 4
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- ntpd
Issue
- What to do if
ntpdlogsfrequency 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
Resolution
Adjusting the time with ntpd -qg
-
As a first approach to solve the issue, the
ntpdservice should be stopped and the time be adjusted manually with the-qgoption. -
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
ntpd):
# service ntpd stop
# ntpd -qg
# service ntpd start
- Information about the above options from man page :-
-g
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.
-q
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
Root Cause
-
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.
Diagnostic Steps
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 RHEL7tickadjcould 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.
-
Product(s)
- Red Hat Enterprise Linux
-
Component
- ntp
-
Category
- Troubleshoot
-
Tags
- rhel
- rhel_4
- rhel_5
- rhel_6
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.
I’m getting this error on my PC:
frequency error -1732 PPM exceeds tolerance 500 PPM
Any ideas?
asked Apr 12, 2012 at 8:44
This means that the difference between your local time and the server you’re syncing with has exceed ntpd‘s limit. ntpd will only sync the local time if it is relatively close to the time server. This is why Red Hat (as an example) uses ntpdate the first time you start the ntpd service to set the local time to be in the right ball park. You should also make sure that the ntp servers you are syncing with are relatively close.
You can do these steps manually if you want (e.g. you’re not running Red Hat which includes the ntpdate step in it’s restart script):
# /etc/init.d/ntpd stop
# ntpdate <ip address of time server>
# /etc/init.d/ntpd start
However, if you’re seeing these errors in a log file for a machine that has been up sometime and it is a virtual machine then there may be a different issue at play. Virtual Machines have problems with their time because there isn’t a proper hardware timing signal coming in. Follow VMWare’s advice found here (it is equally relevant for other virtualisation platforms):
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
Or NTP’s advice here:
http://twiki.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2.
Microsoft Hyper V docs reference the VMWare stuff above for when running Linux on their virtualisation platform.
answered Apr 12, 2012 at 11:17
webtoewebtoe
1,94611 silver badges12 bronze badges
3
You tagged this with «Windows», so I am assuming you are running the reference implementation of ntpd under Windows using the installer from Meinberg.
Meinberg suggests the following command line args
ntpd.exe -U 3 -g -M
-g lets it make a big jump on launch, avoiding the need to run ntpdate. The -M option (Windows-specific) adjusts the «multimedia timer» setting to avoid problems when other applications access this timer. However I found one machine where ntpd simply would not work right with the -M option; offset and jitter started small but increased without bound. After removing that option it works fine. So if you find the feedback loop won’t close under Windows, try changing the state of the -M option.
answered Aug 21, 2012 at 4:20
| View previous topic :: View next topic | |||||||||||||||||
| Author | Message | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| w.hill Tux’s lil’ helper  
Joined: 23 Jan 2005 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
 |
|||||||||||||||||
| hvengel Guru 
Joined: 19 Sep 2004 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| w.hill Tux’s lil’ helper
Joined: 23 Jan 2005 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| hvengel Guru
Joined: 19 Sep 2004 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| w.hill Tux’s lil’ helper
Joined: 23 Jan 2005 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| hvengel Guru
Joined: 19 Sep 2004 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| w.hill Tux’s lil’ helper
Joined: 23 Jan 2005 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| Weeve Retired Dev 
Joined: 30 Oct 2002 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| hvengel Guru
Joined: 19 Sep 2004 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| Aiken Apprentice 
Joined: 22 Jan 2003 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| hvengel Guru
Joined: 19 Sep 2004 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| Aiken Apprentice
Joined: 22 Jan 2003 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| w.hill Tux’s lil’ helper
Joined: 23 Jan 2005 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| Aiken Apprentice
Joined: 22 Jan 2003 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
| w.hill Tux’s lil’ helper
Joined: 23 Jan 2005 |
|
||||||||||||||||
| Back to top |
|
||||||||||||||||
|
|||||||||||||||||
|
|
You cannot post new topics in this forum |
ntpd не синхронизируется и не по нему не синхронизнешься
Re: ntpd не синхронизируется и не по нему не синхронизнешься
udp 123 порт в firewall открыл?
Re: ntpd не синхронизируется и не по нему не синхронизнешься
Я его и не закрывал. Кроме того, ntpdate работает ведь. Оно ж на тот же порт вешается, что и ntpd.
Аналогичная фигня на другом сервере (совсем без фаерволов, на очень приличном канале — я у себя на пинг пенял, но там пинг — на высоте). Конфиг там — идентичный.
Re: ntpd не синхронизируется и не по нему не синхронизнешься
Попробуй убрать все restrict опции. ИМХО они могут быть записаны только в виде ip-адресов, а не DNS имен.
Re: ntpd не синхронизируется и не по нему не синхронизнешься
а может быть у него еще пока не тот stratum?
Re: ntpd не синхронизируется и не по нему не синхронизнешься
Это «пока» длится не первые сутки. Да и сам себе он не правит часы..
ща попробую сделать синхронизацию по IP, а не доменам
Re: ntpd не синхронизируется и не по нему не синхронизнешься
Поделитесь рабочим конфигом, плз. С статическими IP-адресами вроде начало синхронизироваться:
22 Feb 16:07:47 ntpd[21774]: frequency error -512 PPM exceeds tolerance 500 PPM 22 Feb 16:25:11 ntpd[21774]: time reset +0.351048 s 22 Feb 16:34:45 ntpd[21774]: synchronized to 62.4.94.211, stratum=2 22 Feb 16:46:35 ntpd[21774]: time reset +0.159243 s 22 Feb 16:56:14 ntpd[21774]: synchronized to 62.4.94.211, stratum=2 22 Feb 17:47:42 ntpd[21774]: synchronized to 202.49.159.9, stratum=2 22 Feb 17:59:45 ntpd[21774]: no servers reachable 22 Feb 18:01:37 ntpd[21774]: synchronized to 212.23.29.225, stratum=3 22 Feb 18:10:30 ntpd[21774]: synchronized to 202.49.159.9, stratum=2 22 Feb 18:29:41 ntpd[21774]: no servers reachable
но потом снова в логах полная тишина. При попытке синхронизации по этому серверу старая история — stratum 0
Источник
Why does ntpd error message » ntpd[xxxx]: frequency error -512 PPM exceeds tolerance 500 PPM » displayed in /var/log/messages?
Environment
- Red Hat Enterprise Linux 4
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- ntpd
Issue
- What to do if ntpd logs frequency error -3017 PPM exceeds tolerance 500 PPM output like below?
Resolution
Adjusting the time with ntpd -qg
As a first approach to solve the issue, the ntpd service should be stopped and the time be adjusted manually with the -qg option.
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 ntpd ):
- Information about the above options from man page :-
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.
Root Cause
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.
Diagnostic Steps
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.
- Product(s)
- Red Hat Enterprise Linux
- Component
- ntp
- Category
- Troubleshoot
- Tags
- rhel
- rhel_4
- rhel_5
- rhel_6
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.
Источник
Frequency error 500 ppm exceeds tolerance 500 ppm
I’m running NTPD Ver. 4.2.4p5 on a Sun Blade 100 2.6.26.7
I’m getting a huge offset (see below) and a drift rate > than NTP can correct. ‘frequency error 672 PPM exceeds tolerance 500’. It appears as though the error is bigger than NTPD can correct.
‘Googling’ about it would appear that there was a problem with the system clock of Sun Blade 100s and some other Sun boxes of the same era. Sun released a SOLARIS patch to fix the problem but I can’t find a solution under LINUX.
Does anyone else have a Sun with the same problem? Have you found a fix?
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.6.2 121.94.159.255 2 u 40 64 377 0.332 45320.0 149.166
192.168.6.1 132.237.215.255 2 u 22 64 377 0.368 45122.0 182.936
+202.60.65.243 128.250.36.2 2 u 129 64 376 85.482 45291.5 123.218
+192.189.54.33 128.250.37.2 2 u 41 64 377 65.122 45230.7 104.509
+192.189.54.17 128.250.37.2 2 u 55 64 377 55.836 45138.0 151.887
*202.60.94.15 128.250.36.3 2 u 9 64 357 80.266 45290.7 131.936 Вернуться к началу
hvengel
Guru
Зарегистрирован: 19 сен 2004
Сообщений: 515
| Добавлено: вс ноя 23, 2008 11:19 pm Заголовок сообщения: | |
| The max tolerance is set in /include/ntp_proto.h by
#define NTP_MAXFREQ 500e-6 One possible «fix» would be to change this to a higher values so that ntp does not panic on your system. You might consider changing this to: #define NTP_MAXFREQ 700e-6 before building your ntp and this should allow ntp to work. The main reason for the 500PPM limit is more as a sanity check as ntpd will actually work with higher frequency offsets. The author of the ntp code would likely say something about the code possibly not being stable with larger frequency offsets but you are close to 500 PPM so it will likely be OK. It is is not stable you will know it soon enough. Looking at your ntpq output I see some other things that might be issues. For example you jitter numbers are in the 100 to 180 milliseconds range. This is way too much and is an indication of a serious problems either with your network connection or your selected ntp servers. You should be seeing jitter numbers that are closer to 1 millisecond. Your offsets are also very high at around 45 seconds. It appears that you have two ntp servers on your local network (192.168.6.2 and 192.168.6.1). Do these servers also have high jitter and offset numbers? |
Вернуться к началу
w.hill
Tux’s lil’ helper
Зарегистрирован: 23 янв 2005
Сообщений: 133
Откуда: Perth, Western Australia
| Добавлено: чт ноя 27, 2008 8:43 am Заголовок сообщения: | |
| Hi,
I’m running the same version of ntpd on an Ultra 5 attached to the same switch so the network can’t be a problem. I suppose there could be a problem with the SunBlade’s NIC driver I recompile NTPD and see what happens. # ntpq -pn |
Вернуться к началу
hvengel
Guru
Зарегистрирован: 19 сен 2004
Сообщений: 515
| Добавлено: чт ноя 27, 2008 9:39 pm Заголовок сообщения: | |
| Did you alter the NTP_MAXFREQ value?
Things are looking better with your current setup. All of your offsets are |
Вернуться к началу
w.hill
Tux’s lil’ helper
Зарегистрирован: 23 янв 2005
Сообщений: 133
Откуда: Perth, Western Australia
| Добавлено: пт ноя 28, 2008 5:31 am Заголовок сообщения: | |
| I did alter the NTP_MAXFREQ to 700e- as suggested.
I’ve modified /etc/ntp/conf to point only to local PCs. 192.168.6.2 and 192.168.6.1 are both gateway PCs (redundant links). 6.6 is the Ultra 5 host which also functions as a DNS server The SunBlade 100 server requires constant adjustments by ntpd — approximately +0.7s / 15 minutes (see below). It is under no load (standby DNS) # ntpq -pn Nov 28 09:25:58 atlas ntpd[16472]: time reset +0.835382 s Nov 28 11:02:53 atlas ntpd[16472]: time reset +0.744804 s |
Вернуться к началу
hvengel
Guru
Зарегистрирован: 19 сен 2004
Сообщений: 515
| Добавлено: сб ноя 29, 2008 7:12 pm Заголовок сообщения: | |
| It is better than it was but is still having major issues. ntp should only need to make a step adjustment when it first starts and the fact that it is doing this about every 15 minutes is an indication that something is very wrong. By default ntpd will make step adjustments when the time is off by more than 128 milliseconds. When you do an ntpq -c rv what is the frequency? I have a gut feeling that it will be 700PPM. If that is the case then you need to make a bigger adjustment to NTP_MAXFREQ but at best this «fix» is a hack. An error of 2.8 sec/hour (0.7 secs/ 15 minutes) is on the order of 900PPM and if ntp has an adjustment of 700PPM in place then uncorrected raw clock frequency is off by about 1600PPM (or more). Not good. Those who are «time nuts» try to find machines that will drift by less than 40PPM when free running (IE. no ntp) and preferably under 20PPM. Machines with higher levels of free running drift are generally not good time keepers and your machine is way outside of the normal range (Ie. almost all machines are /sys/devices/system/clocksource/clocksource0/current_clocksource
For some of these timers you might need to change your kernel configuration to make them available and you might also need to change your kernel boot parms. Only the tsc timer could be affected by power management all of the others should keep relatively constant time no matter what power mode the processor is in. The big advantages of the tsc timer is that it has higher resolution than the others (some have a resolution of less than 1 nanosecond) and has much lower (on the order of 1000 to 1) CPU overhead to read. But these advantages are only relevant if the timer is power state invariant. In some cases turning off power management features will make the tsc timer invariant. |
Вернуться к началу
w.hill
Tux’s lil’ helper
Зарегистрирован: 23 янв 2005
Сообщений: 133
Откуда: Perth, Western Australia
| Добавлено: ср дек 03, 2008 11:12 pm Заголовок сообщения: | |
| Hi,
# ntpq -c rv # uname -a # cat /sys/devices/system/clocksource/clocksource0/current_clocksource # cat /sys/devices/system/clocksource/clocksource0/available_clocksource When I tried to change to ‘jiffies’ the server locked up & had to be powered down. I’ll have to examine more closely the kernel settings for the various timers. W. |
Вернуться к началу
Weeve
Retired Dev
Зарегистрирован: 30 окт 2002
Сообщений: 641
| Добавлено: пн дек 15, 2008 6:04 pm Заголовок сообщения: | |
| I’ve noticed that SPARC systems often are quite good at having time creep in this fashion (even with Solaris IIRC). To help combat this in the past, I’ve used ntp plus a daily cron job to change the time to match the NTP server’s time, in case the creep has gotten too bad. |
Вернуться к началу
hvengel
Guru
Зарегистрирован: 19 сен 2004
Сообщений: 515
| Добавлено: вс дек 21, 2008 11:56 pm Заголовок сообщения: | ||
Doing this is a desperate action to take. This causes your system time to jump and if it jumps backwards it can cause processes that need the system time to be monotonic to have problems. You should be raising hell with the hardware vendor over this issue if it is in fact as wide spread as you say it is. FYI the correct term is drift not creep. I notice that the OP is using kernel version 2.6.26.7. Starting with version 2.6.26 the linux kernel went from being a micro second kernel to being a nano second kernel. The issue is that glibc contains the time related headers that are used by ntp and glibc has not changed it’s time related headers since linux was verion 2.2.something. So glibc is out of sync with these newer kernels. When ntp is built using the older timex.h headers from glibc with a newer kernel ntp will be trying to make adjustments that are off by 3 orders of magnitude. It may not have much affect on your issue but have you tried using a slightly older kernel (anything before the 2.6.26 series)? I think that this problem could be adjusted in the kernel if you didn’t mind hacking it. There was a long thread earlier this year on the kernel mailing list dealing with issues related to clock tick granularity and incorrect clock rates. The thread is long and contentious but it does have some patches that relate to this (perhaps indirectly) that may point you to the correct place to do what needs to be done. It can be located here: You might also consider contacting one of those involved in the thread to see if perhaps they can help you patch up your kernel and perhaps also make those patches part of some future kernel release. |
Вернуться к началу
Aiken
Apprentice
Зарегистрирован: 22 янв 2003
Сообщений: 237
Откуда: Toowoomba/Australia
| Добавлено: вс янв 04, 2009 3:04 am Заголовок сообщения: | ||||||
There is a flag that is used to tell the kernel if the offset being given is micro or nano. The kernel will scale the offset if need be. With the blade 100 it does not seem to be hard to find information saying they have bad clocks.
Multitply the offset given by the 2nd ntpdate by 10000 and you have a rough estimate of the drift. Below are various values given to tickadj with the approximate drift rates I get on my blade 100. This is done with ntp not running.
I do «tickadj 10012» at boot time. Ntp is reporting a drift of -20.2. Currently using a 2.6.26-gentoo-r1 kernel. edit: replaced ultra 100 with blade 100 edit2: Last night I put freebsd 7.1 on my blade 100. The drift was 398. Even if 2.6.26 adds a static component to the drift value as per the link hvengel gave, the clock is still border line with freebsd. My time server has a 2.6.24 kernel and it did have the static component in the drift value as per that thread. |
Вернуться к началу
hvengel
Guru
Зарегистрирован: 19 сен 2004
Сообщений: 515
| Добавлено: пт янв 09, 2009 9:26 pm Заголовок сообщения: | ||||||||||||
Yes there is a flag that allows ntp and the kernel to agree if things are nano or micro. But at least with the current nanosecond linux kernels with a micro only ntp (IE. ntp build with an unpatched version of glibc) the clock is not very stable. The instability probably will not be apparent if you are using public Internet ntp servers as your time source since this will typically result in offsets that are significantly larger than the error introduced by this issue. But if you are using a high accuracy local reference clock like a GPS the problem is apparent and the time will swing back and forth across a zero offset by about 500 microseconds. With ntp compiled to work in nanosecond mode (IE. using a patched glibc) this is reduced to around +-20 microseconds max and it is usually less. For the OP’s server rootdispersion=2.325 which it typical when using public Internet time servers. Rootdispersion is a measure of the amount of variance or noise in the time source. This is caused by things like variable network latency, asymmetric network delays and other factors. In this case it is about 2.3 milliseconds. With a correctly setup local reference clock/glibc/ntp this will be closer to 0.35 most of the time. For example this is a machine running a LinuxPPS patched 2.6.26 kernel, a nano second patched glibc and using a Motorola Oncore UT+ reference clock:
As you can see the offset in the above ntp querys is less than 6 microseconds and rootdispersion is close to 0.35. This system is close to the bleeding edge as far as time keeping on Linux is concerned. In this case rootdispersion mainly reflects things like variable latencies in the PPS interrupt handler and temperature fluctuations that affect the quartz oscillator on the computer motherboard which is probably the biggest factor affecting this. The reference clock PPS pulses are +-50 nanoseconds of the UTC seconds epoch which is almost two orders of magnitude below the other factors that affect rootdispersion. I have run this same basic system with both a stock glibc and a nanosecond patched glibc and this is where I am getting my +-500 microsecond offset number from. Most of those using the LinuxPPS patchs have seen similar results and the general consensus is that these newer kernels need a nano second patched glibc and an ntp built against this version to give optimum timekeeping results.
This is good to know. |
Вернуться к началу
Aiken
Apprentice
Зарегистрирован: 22 янв 2003
Сообщений: 237
Откуда: Toowoomba/Australia
| Добавлено: вс янв 11, 2009 3:22 pm Заголовок сообщения: | ||||
It is not just current kernels and a micro ntp. The slow convergence goes back to 2.6.18 and the offsets you are complaining about were not uncommon. Great for dialup but I really disliked it when using pps. 2.6.17 and earlier could react quite quickly. If your offset is 2345 and STA_NANO is set then 2345 is used. If STA_NANO is not set then 2 * NSEC_USEC (ie 2000) will be used. I don’t see that making a lot of difference. All I can think of at this late hour is ntp gives the kernel different time constants to use depending on nano (time constant unmodified) or micro (ntp time constant — 4). For micro the kernel then adds 4. With micro the kernel is not using the time constant that ntp is telling it. The time I modified the kernel so that it used the time constant it was given with micro I found convergence was much better. As for a glibc patch I did not do much for nano support in ntp. All I did was add STA_NANO and friends the the glibc sys/timex.h. This is with a garmin gps25, unpatched (except for timex.h) glibc 2.6.1 and a 2.6.24 kernel + linuxpps + other mods.
Back onto the original topic. My blade is being put back into use and I am watching the stability of the clock after using tickadj. The only thing I have seen so far is the effects of it being in a room that changes by 10 — 15C during the day. Based on the tickadj data I have previously posted for my blade I used tickadj 10012. hvengel, where that thread you linked to really bit me was with my alpha. Drift was 210ppm or so and when that problem was introduced it changed to high 490s’ A hot day would have it hitting the limit of what ntp could handle. |
Вернуться к началу
w.hill
Tux’s lil’ helper
Зарегистрирован: 23 янв 2005
Сообщений: 133
Откуда: Perth, Western Australia
| Добавлено: пт дек 04, 2009 6:44 am Заголовок сообщения: | |
| Hi,
Thanks to everyone for all the help above. After much experimentation I arrived at: tick = 10007 — (Somewhere between 10007 and 10008) on: Linux atlas 2.6.30-gentoo-r8 #3 Mon Nov 30 11:25:20 WST 2009 sparc64 sun4u TI UltraSparc IIe (Hummingbird) GNU/Linux Using: ntpd 4.2.4p7@1.1607-o What should I do to ensure that the tick time is persistent between reboots? Not that they occur that often. Is there a kernel header file I can alter || can it be done at boot time? Thanks. |
Вернуться к началу
Aiken
Apprentice
Зарегистрирован: 22 янв 2003
Сообщений: 237
Откуда: Toowoomba/Australia
| Добавлено: пт дек 04, 2009 8:15 am Заголовок сообщения: | |
| One thought is add it /etc/conf.d/local.start
Seems to be a place to add programs you want run at start up. |
Вернуться к началу
w.hill
Tux’s lil’ helper
Зарегистрирован: 23 янв 2005
Сообщений: 133
Откуда: Perth, Western Australia
| Добавлено: сб дек 05, 2009 3:55 am Заголовок сообщения: | |
| That worked.
Thanks. |
Вернуться к началу
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Copyright 2001-2023 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy
Источник
Adblock
detector