Re: [ntp:questions] NTP not syncing
4.2.4 is way way old. (ntp releases are infrequent to begin with and the current version is 4.2.6 and that is already quite old.) Besides, the problem went away when you deleted the drift file and restarted ntpd. So I'd say that was likely to be your problem. Looks like the general consensus is that the NTP version I am using is likely to be a major cause of trouble. That helps a lot, would explain quite a lot of random issues I've seen. Thanks guys, you've been great, your help is greatly appreciated! Antonio ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
Today drift is 60 and offsets are around 8. Looks good. You know what's good? from: ntp3.lordynet.org NetBSD-6.1, i386, ntpd 4.2.6p5: $ cat /var/db/ntp/ntpd.drift -9.722 from ntpq -crv offset=-0.061 Your ntpd 4.2.4 is from 2008 through 2009 and offsets with that version might not have been much worse than from 4.2.6p5 but correction of drift above 50 ppm was not good or even impossible. Ntpd 4.2.6p5 also converges to a reasonable low offset much faster after ntpd is restarted. I have an idea that ntpd 4.2.8 is very near to release. That's great to know, thanks. I will speak with the manufacturer and see if a newer version can be adopted. It's good to know that it may well be a limitation of the NTP version being used. Today I've been told that on newer machines I can enable the HPET (high precision event time) in the BIOS if available and that should give a better clock to begin with. Your problem may not be with the setup of ntpd and you really need to know what cpu optimisations, if any, are enabled. Some optimisations for energy consumption are incompatible with running an ntpd service. I can't help you with bios settings or diagnostics for your motherboard settings. You might find some information in dmesg but again that requires familiarity with your hardware. I will check the CPU optimisation as soon as I'm in front of one of these servers. Thanks for your help David Antonio ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
If the oscillator drifts from last drift-file write, outside of +/- 15 ppm if I recall it, it fails to lock in again. It would be good if it could bail out and do normal frequency acquisition if that occurs. That particular feature have bitten hard, and was a side-consequence of other faults, but none-the-less. Thanks Magnus, I saw the bug report you filed. Would it be wiser to delete the drift file at boot - by script - and let ntpd resync and recreate a new drift file? As mentioned, I don't really need my system to be synced down to the millisecond, if ntpd takes a few hours to settle and the time is off up to a few seconds during that time it's perfectly fine with me. Thanks Antonio ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
Hi-- On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli pu...@me.la wrote: Would it be wiser to delete the drift file at boot - by script - and let ntpd resync and recreate a new drift file? Normally, no. The drift file lets ntpd perform a first-order correction of the average intrinsic drift of the local clock even if ntpd can't get time from any other sources. However, if the drift can't be computed correctly because of some unusual problem-- and a systemic drift of over 500ppm is fairly unusual-- then deleting the drift file might help. As mentioned, I don't really need my system to be synced down to the millisecond, if ntpd takes a few hours to settle and the time is off up to a few seconds during that time it's perfectly fine with me. Gracious. In that case, run ntpdate via cron every hour or so and you'll probably stay within that tolerance even if ntpd itself can't manage to stay in sync. However, if switching your system's clock source from whatever you are using now to HPET, ACPI, etc improves matters so that ntpd remains stable, that would obviously provide much better timekeeping. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
On 04/11/2013 18:49, Charles Swiger wrote: Hi-- On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli pu...@me.la wrote: Would it be wiser to delete the drift file at boot - by script - and let ntpd resync and recreate a new drift file? Normally, no. The drift file lets ntpd perform a first-order correction of the average intrinsic drift of the local clock even if ntpd can't get time from any other sources. However, if the drift can't be computed correctly because of some unusual problem-- and a systemic drift of over 500ppm is fairly unusual-- then deleting the drift file might help. Understood. I'll do some tests to find out whether with a better configuration the drift file still gets stuck to 500. In that case I'll have it deleted at each startup to see if things improve As mentioned, I don't really need my system to be synced down to the millisecond, if ntpd takes a few hours to settle and the time is off up to a few seconds during that time it's perfectly fine with me. Gracious. In that case, run ntpdate via cron every hour or so and you'll probably stay within that tolerance even if ntpd itself can't manage to stay in sync. However, if switching your system's clock source from whatever you are using now to HPET, ACPI, etc improves matters so that ntpd remains stable, that would obviously provide much better timekeeping. That is being considered. The server runs a maintenance procedure every 24hours when all the services are stopped momentarily. It could be the right time for an ntpdate to run. Thanks Antonio ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
Running ntpdate every hour instead of running ntpd won't work if there are database servers or dovecot or other apps that require monotonic time. But if the system clock is always running slow this *probably* won't be an issue, and it also again points to lost clock interrupts. Better to solve the underlying problem. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
On 2013-11-03, Antonio Marcheselli pu...@me.la wrote: On 03/11/2013 05:55, David Taylor wrote: On 02/11/2013 20:41, unruh wrote: On 2013-11-02, antonio.marchese...@gmail.com antonio.marchese...@gmail.com wrote: [] How can I verify if the stepping has been disabled or not? ntp.drift at the moment is -500.000 Which is way out of spec and cannot be corrected by ntpd. Yes, it can be corrected. There are ways of offsetting NTP to allow for clocks which are more than 500 ppm off nominal. Likely it's OS-dependant, but for Windows I documented the method here: http://www.satsignal.eu/ntp/setup.html#broken-clock There is information about fixing this issue in the NTP Community Supported Documentation at https://support.ntp.org/bin/view/Support/KnownHardwareIssues#Section_9.1.6. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
On Nov 4, 2013, at 11:36 AM, Harlan Stenn st...@ntp.org wrote: Running ntpdate every hour instead of running ntpd won't work if there are database servers or dovecot or other apps that require monotonic time. Did you somehow know whether the existing 500+ ppm drift is stable? But if the system clock is always running slow this *probably* won't be an issue, and it also again points to lost clock interrupts. Better to solve the underlying problem. Yes, it's best to solve the underlying problem. Lost interrupts, a flaky XO, operating system bugs, etc are all possible. Some of these might be easy to fix though, ie, by choosing a different system clock source... Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
On 2013-11-04, Antonio Marcheselli pu...@me.la wrote: That is being considered. The server runs a maintenance procedure every 24hours when all the services are stopped momentarily. It could be the right time for an ntpdate to run. ntpd continuously disciplines the system clock (i.e. attempts to steer it towards the aparent correct time). ntpdate (or sntp) merely adjusts the system clock once each time the utility is run. The system clock will then drift until the next correction. When faced with a system clock which is drifting monotonically at 400 to 500PPM the best course of action is to bite the bullet and determine a sane tick value. In virtually all cases this will allow ntpd to control your clock. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
On 04/11/2013 19:50, Charles Swiger wrote: On Nov 4, 2013, at 11:36 AM, Harlan Stenn st...@ntp.org wrote: Running ntpdate every hour instead of running ntpd won't work if there are database servers or dovecot or other apps that require monotonic time. Did you somehow know whether the existing 500+ ppm drift is stable? I'm monitoring the drift files of the three servers. The server which got stuck on -500.000 is now on -62, stable. Another server which gave frequency error is now on -430, stable - I guess when the server is rebooted it's likely to give frequency error again while ntpd locks on the frequency? So it looks like that the first server has no clock issues and the initial problem was NTP related. The second server has a clock issue, which I'll try to look into. Thanks Antonio ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
On 2013-11-04, Charles Swiger cswi...@mac.com wrote: Hi-- On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli pu...@me.la wrote: Would it be wiser to delete the drift file at boot - by script - and let ntpd resync and recreate a new drift file? Normally, no. The drift file lets ntpd perform a first-order correction of the average intrinsic drift of the local clock even if ntpd can't get time from any other sources. However, if the drift can't be computed correctly because of some unusual problem-- and a systemic drift of over 500ppm is fairly unusual-- then deleting the drift file might help. It used to be on older version of linux, that the calibration of the computer clock on boot was off. Thus the calibration would mean that the clock rate would vary by 50-100PPM on successive reboots. This would make the drift file pretty useless. As mentioned, I don't really need my system to be synced down to the millisecond, if ntpd takes a few hours to settle and the time is off up to a few seconds during that time it's perfectly fine with me. Gracious. In that case, run ntpdate via cron every hour or so and you'll probably stay within that tolerance even if ntpd itself can't manage to stay in sync. However, if switching your system's clock source from whatever you are using now to HPET, ACPI, etc improves matters so that ntpd remains stable, that would obviously provide much better timekeeping. Regards, ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing
Antonio, On 11/04/2013 06:40 PM, Antonio Marcheselli wrote: If the oscillator drifts from last drift-file write, outside of +/- 15 ppm if I recall it, it fails to lock in again. It would be good if it could bail out and do normal frequency acquisition if that occurs. That particular feature have bitten hard, and was a side-consequence of other faults, but none-the-less. Thanks Magnus, I saw the bug report you filed. Would it be wiser to delete the drift file at boot - by script - and let ntpd resync and recreate a new drift file? As mentioned, I don't really need my system to be synced down to the millisecond, if ntpd takes a few hours to settle and the time is off up to a few seconds during that time it's perfectly fine with me. If you don't want the bootstrap feature of drift-file, don't specify it in the configuration is much wiser than deleting it. It's good to have this acceleration, if we can make it to be fool-proof. This is an attempt to get in that direction. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP clients
On 05/11/2013 01:57, Nomen Nescio wrote: simple command AFIK. As ntpd can also be configured to broadcast time, How? Could you point me out on relevant FAQ? https://www.google.co.uk/search?q=ntp+broadcast may help. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
