Re: [time-nuts] Tracking NTP displacement and correlationbetweentwo clients.
David, The problem is that they start in sync and over the course of a day drift that far apart despite having NTP running. We're not sure why NTP isn't correcting it along the way. Though at this point, we are looking at a firmware bug. Thanks! Bob === Bob, I take it that you are booting the PC at the start of the day, and it syncs to NTP servers at that time? If the internal clock is off (when undisciplined) by more than 500 ppm (43 seconds/day) NTP will not control it. I suggest measuring the clock error when it is not being controlled by NTP, and then we can progress. (Or you find the firmware problem). Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Tracking NTP displacement and correlationbetweentwo clients.
That is his point. Initial time comes from MB clock. System (OS) time is set from that at boot. During NTP startup for a client it is normal to do a ntpdate to hard set the OS clock (direct one time set). From there ntpd would track and adjust. HOWEVER, there are limits to how much ntpd will skew the clock to keep it in sync. If the OS clock is drifting faster than this amount ntpd will not be able to adjust it fast enough. Think bad hardware or buggy BIOS, OS clock ends up running too fast or too slow for ntpd to compensate for. On 10/5/12 12:46 AM, David J Taylor wrote: David, The problem is that they start in sync and over the course of a day drift that far apart despite having NTP running. We're not sure why NTP isn't correcting it along the way. Though at this point, we are looking at a firmware bug. Thanks! Bob === Bob, I take it that you are booting the PC at the start of the day, and it syncs to NTP servers at that time? If the internal clock is off (when undisciplined) by more than 500 ppm (43 seconds/day) NTP will not control it. I suggest measuring the clock error when it is not being controlled by NTP, and then we can progress. (Or you find the firmware problem). Cheers, David ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Tracking NTP displacement and correlationbetweentwo clients.
On 10/05/2012 08:23 PM, Christopher Brown wrote: That is his point. Initial time comes from MB clock. System (OS) time is set from that at boot. During NTP startup for a client it is normal to do a ntpdate to hard set the OS clock (direct one time set). From there ntpd would track and adjust. HOWEVER, there are limits to how much ntpd will skew the clock to keep it in sync. If the OS clock is drifting faster than this amount ntpd will not be able to adjust it fast enough. Think bad hardware or buggy BIOS, OS clock ends up running too fast or too slow for ntpd to compensate for. Buggy OS has been known to do this before. Lack of kernel support is a real killer. What are you running? There is another point to make for servers. Since NTP will not trust clocks being more than +/- 15 min away from the system time, if the HW clock drifted to far away over the months and maybe years since boot, then when it initiate the system time on next boot it may lock the NTP training out. A good way to mitigate this is to have a cron job to transfer system time over to HW clock time regularly, maybe once a week or once a month. That way, if the server goes down uncontrolled (at which time it is expected to do this, if you are lucky) the HW clock won't be too far off anyway for things to resolve itself by automagic. Oh, I learned this the hard way when we had a power failure in the computer hall. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
