[ale] Solved - Re: Issues with NTP - synchronizes, then falls behind...
Stephen R. Blevins
srblevi at worldnet.att.net
Sun Jul 26 15:08:33 EDT 2009
Don't know if they support NTP, but the NIST Time and Frequency Division
may be of help. http://tf.nist.gov/
YMMV.
Stephen R. Blevins
srblevi at worldnet.att.net
Chris Woodfield wrote:
> After some more poking around, managed to get this fixed, but figured
> I'd share the solution...
>
> The problem wasn't anything in ntp - it was, in fact, a crappy
> internal clocksource. However, on most systems there are multiple
> clock sources available, and changing them is only an echo $source > /
> sysfile away.
>
> Specifically on my box, the magic command was:
>
> tino:~# cat /sys/devices/system/clocksource/clocksource0/
> available_clocksource
> tsc hpet acpi_pm jiffies
> tino:~# cat /sys/devices/system/clocksource/clocksource0/
> current_clocksource
> tsc
> tino:~# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/
> current_clocksource
> tino:~# cat /sys/devices/system/clocksource/clocksource0/
> current_clocksource
> acpi_pm
>
> Then, in /boot/grub/menu.lst, add "clocksource=acpi_pm" to your kernel
> boot command args.
>
> I picked "acpi_pm" because that seems to be the source most often
> mentioned in the googled results I found when looking this up.
> However, I couldn't seem to find anywhere was any sort of
> documentation on what each of these clocksources actually *are*.
> Anyone able to explain this further?
>
> Thanks,
>
> -Chris
>
> On Jul 26, 2009, at 11:57 AM, Chris Woodfield wrote:
>
>> Hi,
>>
>> Having a major problem with a server that's running Debian 4.0 - can't
>> seem to keep the clock in sync.
>>
>> I believe that the root cause is that my motherboard's hardware clock
>> is running slow, but I'm trusting that ntpd should correct for that -
>> which it is not.
>>
>> When I start ntp up, it connects to multiple pool.ntp.org servers, and
>> appears to properly synch up the internal clock. However, within a few
>> minutes, that clock is several seconds behind - what's more is that
>> ntp seems to detect this, as shown in the offset field of ntpq -p, but
>> doesn't seem interesting in correcting it.
>>
>> As the diag shows below, I'm skewing a full 10 seconds within 10
>> minutes - is this just too far of a delta for ntp to be able to work
>> with? If so, is there a config option to resolve this?
>>
>> Here's a quick shell script I wrote to demonstrate the problem -
>> 192.168.0.155 is a Mac that syncs to time.apple.com.
>>
>> --
>> echo -n "Initial Localtime: "
>> date
>> echo -n "Initial RemoteTime: "
>> ssh 192.168.0.155 date
>> sudo /etc/init.d/ntp restart
>> for VAR in 1 2 3 4 5
>> do
>> sleep 90
>> ntpq -p
>> echo -n "Localtime: "
>> date
>> echo -n "Remotetime: "
>> ssh 192.168.0.155 date
>> done
>> --
>>
>> And the output - note that on first run, it goes from 6 seconds behind
>> before ntp restart to ~2 seconds, but then drifts out to a full 10
>> seconds behind at the end of the 450 seconds it takes the script to
>> run.
>>
>> rekoil at tino:~$ sh ntp_run
>> Initial Localtime: Sun Jul 26 11:45:34 EDT 2009
>> Initial RemoteTime: Sun Jul 26 11:45:40 EDT 2009
>> Stopping NTP server: ntpd.
>> Starting NTP server: ntpd.
>> remote refid st t when poll reach delay
>> offset jitter
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> ======================================================================
>> host2.kingrst.c 173.14.47.149 2 u 41 64 1 50.214
>> 844.062 0.001
>> mainframe.cynac 216.218.254.202 2 u 27 64 1 31.627
>> 1142.33 0.001
>> Localtime: Sun Jul 26 11:47:13 EDT 2009
>> Remotetime: Sun Jul 26 11:47:15 EDT 2009
>> remote refid st t when poll reach delay
>> offset jitter
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> ======================================================================
>> host2.kingrst.c 173.14.47.149 2 u 3 64 7 49.684
>> 2195.19 1354.11
>> mainframe.cynac 216.218.254.202 2 u 51 64 3 31.627
>> 1142.33 1393.21
>> Localtime: Sun Jul 26 11:48:43 EDT 2009
>> Remotetime: Sun Jul 26 11:48:47 EDT 2009
>> remote refid st t when poll reach delay
>> offset jitter
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> ======================================================================
>> host2.kingrst.c 173.14.47.149 2 u 28 64 17 49.684
>> 2195.19 1922.28
>> mainframe.cynac 216.218.254.202 2 u 14 64 17 31.310
>> 3886.57 1925.79
>> Localtime: Sun Jul 26 11:50:13 EDT 2009
>> Remotetime: Sun Jul 26 11:50:19 EDT 2009
>> remote refid st t when poll reach delay
>> offset jitter
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> ======================================================================
>> host2.kingrst.c 173.14.47.149 2 u 52 64 37 49.684
>> 2195.19 2647.40
>> mainframe.cynac 216.218.254.202 2 u 38 64 37 31.310
>> 3886.57 2153.12
>> Localtime: Sun Jul 26 11:51:43 EDT 2009
>> Remotetime: Sun Jul 26 11:51:51 EDT 2009
>> remote refid st t when poll reach delay
>> offset jitter
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> ======================================================================
>> host2.kingrst.c 173.14.47.149 2 u 16 64 177 48.996
>> 8992.49 5287.44
>> mainframe.cynac 216.218.254.202 2 u 2 64 177 31.310
>> 3886.57 3275.18
>> Localtime: Sun Jul 26 11:53:14 EDT 2009
>> Remotetime: Sun Jul 26 11:53:24 EDT 2009
>>
>> Relevant config stuff:
>>
>> root 22986 0.0 0.1 5492 1692 ? Ss 11:45 0:00 /usr/
>> sbin/ntpd -p /var/run/ntpd.pid -u 0:0 -g
>> By default Debian 5 runs ntp as UID ntp, changed to root to eliminate
>> potential permissions issues...
>>
>> from ntp.conf:
>> server 0.debian.pool.ntp.org iburst dynamic
>> server 1.debian.pool.ntp.org iburst dynamic
>>
>> Thanks,
>>
>> -Chris
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
>
More information about the Ale
mailing list