[ntp:questions] Cannot sync on embedded PPC running Linux

Richard B. Gilbert rgilbert88 at comcast.net
Tue Jun 16 13:12:25 UTC 2009


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 4.2.4p7 at 1.1607 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.




More information about the questions mailing list