[ntp:questions] ntpd

Dave Hart hart at ntp.org
Wed Aug 3 19:42:19 UTC 2011


On Wed, Aug 3, 2011 at 13:41 UTC, Valera <valera.sigaev at developonbox.ru> wrote:
> I did undef SO_TIMESTAMP for ntpd and execute again. The situation has
> improved, because I see that offset calculates correctly. But I'm not sure
> that the time is adjusted.
> I have next information from ntpq utility:
>
> # /home/mpi/bin/ntpq -p 10.251.16.22
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
>  10.251.231.1    167.206.1.30     3 u    5   64  377    7.252   13.031
> 1.329
> # /home/mpi/bin/ntpq -p 10.251.16.22
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
>  10.251.231.1    167.206.1.30     3 u   49   64  377    8.143   11.555
> 1.103
> uname -a returns the next:
>
> # uname -a
> Linux SamSTB 2.6.18-5.0 #4 Tue Feb 1 04:12:29 KST 2011 97459b0 unknown

That is improvement.  SO_TIMESTAMP has worked for most people using
Linux for ages, so either your embedded platform managed to break it,
or your configure is not being run on the embedded platform and you're
guessing/providing the wrong cross-compilation options to configure
and getting something inappropriate in config.h

When you say you're not sure time is being synched, you are making me
feel like I'm doing your homework.  I wanted to suggest for you to
move this discussion to the programming-oriented
hackers at lists.ntp.org, but hesitate because you could use the help of
questions at lists.ntp.org to understand how to interpret ntpq -p output.

The clock _definitely is not_ being synched because the first column
of the ntpq -p output is not showing a * to indicate 10.251.231.1 is
selected as the time source.  To further diagnose why, it is not
productive to pore over your debug output log when ntpq will do.  Try:

ntpq -c rv -p -c "rv &1" 10.251.16.22

The output of "rv &1", the peer variables for your box's single
source, will include a "flash=" that will tell you why the source is
not being selected.

As you are relying on me to teach you how to troubleshoot ntpd and
help you port it to an embedded platform, e.g. have not done your
homework, expect me to have declining interest in helping you.  I am a
volunteer and I have to feed myself too, so I'm not going to do your
job for you and let you collect the pay.

Cheers,
Dave Hart



More information about the questions mailing list