gizero wrote: > I'm trying to run ntpd 4.2.4p7 on a ppc embedded system running Linux/ > 2.6.24.6. I'm not very accustomed to using NTP daemon, hence I'm > looking for some help in debugging the system, which appear to be > unable to sync with a public NTP server. > > ntptime is always reporting the following (this is after a long while > ntpd was started): > > ~ $ ntptime > ntp_gettime() returns code 5 (ERROR) > time cde22135.b979b000 Tue, Jun 16 2009 13:48:37.724, (.724513), > maximum error 2390032 us, estimated error 16 us > ntp_adjtime() returns code 5 (ERROR) > modes 0x0 (), > offset 0.000 us, frequency 0.000 ppm, interval 1 s, > maximum error 2390032 us, estimated error 16 us, > status 0x40 (UNSYNC), > time constant 4, precision 1.000 us, tolerance 512 ppm, > > I suspect the problem is not the configuration file, since the same is > working well on my workstation. The relevant part of /etc/ntp.conf is: > > ~ $ cat /etc/ntp.conf > # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help > > driftfile /var/lib/ntp/ntp.drift > > # Enable this if you want statistics to be logged. > statsdir /var/log/ntpstats/ > > statistics loopstats peerstats clockstats > filegen loopstats file loopstats type day enable > filegen peerstats file peerstats type day enable > filegen clockstats file clockstats type day enable > > # You do need to talk to an NTP server or two (or three). > server it.pool.ntp.org > > > I tryed to sync with ntpdate against the same server before running > the daemon and it works fine, then I start ntpd as follows (doing it > as root for the moment): > > $ /usr/bin/ntpd -p /var/run/ntpd.pid -g > > What make me suspicious is the result of the query: > > ~ $ ntpq -c peer -c as -c rl > remote refid st t when poll reach delay > offset jitter > ============================================================================== > h180.argonavis. 62.173.184.58 3 u 19 64 1 10.282 > -712292 0.001 > > ind assID status conf reach auth condition last_event cnt > =========================================================== > 1 51207 9014 yes yes none reject reachable 1 > assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart, > version="ntpd [email protected] Tue Jun 16 06:57:45 UTC 2009 (1)", > processor="ppc", system="Linux/2.6.24.6", leap=11, stratum=16, > precision=-20, rootdelay=0.000, rootdispersion=0.300, peer=0, > refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000, > poll=6, clock=cde223b0.c9293112 Tue, Jun 16 2009 13:59:12.785, > state=0, > offset=0.000, frequency=0.000, jitter=0.001, noise=0.001, > stability=0.000 > > What does that "reject" mean? Why are offset and frequency always > counting zero? Is there any relevant Linux Kernel config flags I might > be missing on my system? > > TIA, > Regards, > > Andrea
It looks very much as if your "-g" did not take effect. The offset shown is HUGE! A hasty calculation translates -712292 milliseconds to 197.85 minutes! Ideally you should be using a minimum of four servers but you have configured only one. If possible, add three more servers to your configuration. Restart ntpd. Wait a MINIMUM of 30 minutes and try ntpq again. You may have to wait ten hours before the time is as good as it's going to get. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
