ntpd not synchronizing - again :-( - NTP

This is a discussion on ntpd not synchronizing - again :-( - NTP ; I have just installed Linux (Slackware 10.2) on a box that used to run an older Linux distribution (Slackware 10.0). With this older distribution ntpd was working fine. In the new one it isn't. With ntpd up and running, I ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: ntpd not synchronizing - again :-(

  1. ntpd not synchronizing - again :-(

    I have just installed Linux (Slackware 10.2) on a box that used to
    run an older Linux distribution (Slackware 10.0). With this older
    distribution ntpd was working fine. In the new one it isn't.

    With ntpd up and running, I decided to launch a small script to
    print out regularly the time according to the hardware clock, and the
    output from the ntpdate -q xxx command, where xxx
    is my local NTP server, with IP address 192.168.0.1. This server in
    turn takes its NTP feed from some external ones, and other boxes in my
    LAN synchronize with it without any problems. The first lines of
    output from that script are

    Thu 06 Jul 2006 08:13:15 AM PDT -1.269066 seconds
    server 192.168.0.1, stratum 3, offset -0.103281, delay 0.02702
    6 Jul 08:13:15 ntpdate[3431]: adjust time server 192.168.0.1 offset
    -0.103281 sec

    The very first line is the time as reported by the hardware clock
    (the output from the hwclock --show command) whereas the last two are
    the output from ntpdate -q xxx. In two minute intervals, this is the
    output I got:

    Thu 06 Jul 2006 08:15:19 AM PDT -0.919212 seconds
    server 192.168.0.1, stratum 3, offset -0.384778, delay 0.02705
    6 Jul 08:15:19 ntpdate[3488]: adjust time server 192.168.0.1 offset
    -0.384778 sec

    Thu 06 Jul 2006 08:17:23 AM PDT -0.969468 seconds
    server 192.168.0.1, stratum 3, offset -0.777177, delay 0.02704
    6 Jul 08:17:23 ntpdate[3655]: step time server 192.168.0.1 offset -0.777177 sec

    Thu 06 Jul 2006 08:19:27 AM PDT -0.948820 seconds
    server 192.168.0.1, stratum 3, offset -1.171127, delay 0.02704
    6 Jul 08:19:28 ntpdate[3864]: step time server 192.168.0.1 offset -1.171127 sec

    Thu 06 Jul 2006 08:21:31 AM PDT -0.958195 seconds
    server 192.168.0.1, stratum 3, offset -1.543037, delay 0.02704
    6 Jul 08:21:32 ntpdate[4045]: step time server 192.168.0.1 offset -1.543037 sec

    Thu 06 Jul 2006 08:23:35 AM PDT -0.962411 seconds
    server 192.168.0.1, stratum 3, offset -1.957947, delay 0.02705
    6 Jul 08:23:36 ntpdate[4247]: step time server 192.168.0.1 offset -1.957947 sec

    When I finally stopped it the ouput was

    Thu 06 Jul 2006 08:35:00 AM PDT -0.731368 seconds
    server 192.168.0.1, stratum 3, offset -4.185915, delay 0.02702
    6 Jul 08:35:00 ntpdate[24616]: step time server 192.168.0.1 offset
    -4.185915 sec

    Can anybody explain why the OS clock is drifting so dramatically?
    Also, is it the case that it running in lockstep with the hardware
    clock? I thought that the OS clock and the hardware clock were two
    different things.

    My ntpd configuration file is as follows:

    server 127.127.1.0 # local clock
    fudge 127.127.1.0 stratum 10
    server 192.168.0.1
    driftfile /etc/ntp/drift
    multicastclient # listen on default 224.0.1.1
    broadcastdelay 0.008
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. NTP server

    Hi eveybody;

    Previously I asked NTP server implementation status or related
    recommendations in Vxworks, but I havent get response any one yet except
    Harlan Stenn... That's okay, thanks all.

    During the that time I learned that vxWorks has SNTP client and server
    support.

    In our project there is an izaolated network and one an other computer act
    as NTP server and we havent get yet this computer and our computer which has
    vxWorks OS have to act as NTP client. First thing first I want to test our
    side. Because of this I need NTP server to use it in our local izolated
    network to test our software application which will act as NTP client or for
    beginning act as SNTP client...

    Could anyone recommend where can I find ntp server that can be used in local
    izolated network and how I can setup test enviroment to test our software
    application which will act as NTP client or SNTP client and which
    communicates with NTP server in local izolated network...

    Please let me get response...

    See you all...

    Thanks in advance...
    EGE


    Configuration:
    Tornado 2.02 -> vxWorks 5.4
    Motorola Powerpc target
    Codebase language C++

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  3. Re: NTP server

    ntpd is an ntp client or server. If it is not ported to your machine you
    can either port it (we can help) or see if there is some other ported
    application that wil do it.

    Plan B would be to find an old x86 box, install FreeBSD (or some other free
    os of your choice) and put ntpd on it and use it as your local time server.

    H

  4. Re: ntpd not synchronizing - again :-(

    JCA wrote:
    > Can anybody explain why the OS clock is drifting so dramatically?
    > Also, is it the case that it running in lockstep with the hardware
    > clock? I thought that the OS clock and the hardware clock were two
    > different things.
    >
    > My ntpd configuration file is as follows:
    >
    > server 127.127.1.0 # local clock
    > fudge 127.127.1.0 stratum 10


    Are you serving time to other systems? If not, it's not needed.

    > server 192.168.0.1


    You were querying this server, yet that's the address in here, so I'm
    not sure what you were getting.

    > driftfile /etc/ntp/drift
    > multicastclient # listen on default 224.0.1.1


    There is no default. The address is required. Do you have a multicast
    server set up somewhere? Otherwise this option has no meaning and since
    you didn't disable authentication it will in any case ignore any
    multicast packets that it does receive even if it were configured properly.

    > broadcastdelay 0.008


    On a LAN why would you put this in at all? This should not be here
    unless you have a good measure of the propogation delay AND ntpd is not
    doing its own calculation because it is not querying the multicast
    server at all (it's part of what authentication would do for you).

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


+ Reply to Thread