Hi--
On Oct 14, 2009, at 11:54 AM, PGNet Dev wrote:
assID=0 status=c6c4 sync_alarm, sync_ntp, 12 events,
event_peer/strat_chg,
version="ntpd [email protected] Fri May 8 08:40:54 UTC 2009
(1)",
processor="x86_64", system="Linux/2.6.27.29-0.1-default",
leap=11,
stratum=16, precision=-8, rootdelay=0.000,
rootdispersion=12.045,
peer=20991, refid=ÏÈQq,
reftime=ce809488.581ce45d Wed, Oct 14 2009 11:18:48.344,
poll=6,
clock=ce809b5e.ee919885 Wed, Oct 14 2009 11:47:58.931,
state=2,
---> offset=0.000, frequency=-3.502, jitter=670.815, noise=3.906,
stability=0.393, tai=0
remote refid st t when poll reach delay
offset jitter
=
=
=
=
=
=
=
=
======================================================================
+clock.fmt.he.ne .PPS. 1 u 17 64 377 15.364
-1940.8 675.242
+clock.isc.org .GPS. 1 u 60 64 377 14.370
-1847.6 671.874
+clock.sjc.he.ne .CDMA. 1 u 10 64 377 23.036
-1954.9 667.749
+rrcs-64-183-55- .GPS. 1 u 14 64 377 51.920
-1945.9 672.706
*nist1.aol-ca.tr .ACTS. 1 u 44 64 377 22.909
-1870.8 667.993
i'm guessing this is not coincidence ...
is it indicative of any problem?
Yes, your local time is too far off from the time from the NTP
timesources you have configured, and ntpd probably can't sync time to
them (hence the "sync_alarm" in status), so it's not updating the
values in the line you point out. Stop ntpd, run "ntpdate -b" twice
against some timeserver-- once to correct your clock, once to confirm
that the time has been reset properly, so should have a minimal
correction-- and then restart ntpd.
However, you should also review the maxpoll settings you are using and
which NTP timeservers you are using, because you should not be polling
stratum-1 servers every minute.
Regards,
--
-Chuck
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
