NTP 4.2.2p4 loopstats - NTP

This is a discussion on NTP 4.2.2p4 loopstats - NTP ; Steve - I thank you for your time in replying. Hopefully I can get this operational. The ntp.conf file I appended was installed by the Fedora Core 5 installation except for the NIST servers which were added by the system ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 22 of 22

Thread: NTP 4.2.2p4 loopstats

  1. Re: Not able to connect

    Steve - I thank you for your time in replying. Hopefully I can get this
    operational.

    The ntp.conf file I appended was installed by the Fedora Core 5
    installation except for the NIST servers which were added by the system
    date/time s/w under Fedora Core 5. I have refrained from editing the
    file, since I know nothing about it. I will edit it as per your comments.

    I got the port 13 from the NIST site ( excerpt from their site):
    +++++++++++++++++++++++++++++++++++++++++++++

    The port number on your system is arbitrary, and is usually chosen at
    random by your system each time the client program prepares to make a
    request for the time. Therefore, it is likely to vary from one request
    to another. However, the NIST time servers will only listen for and
    respond to requests addressed to a few specific port numbers and
    protocols. These combinations are:

    * udp port 123, which is used by the network time protocol and the
    simple network time protocol. The NIST client software can be configured
    to use this port, but does not use it by default.

    * tcp port 13, which is used by the NIST client software by default
    and by other programs that use the “daytime” protocol.

    * tcp port 37 and udp port 37, which are used by DATE, RDATE, SDATE
    and by other programs that use the “time” protocol.
    +++++++++++++++++++++++++++++++++++++++++++++++

    following the above, I assumed that TCP port 13 would be the port to
    use. I will correct that. Thanks.

    The NIST site indicated that users (all?) were encouraged to use their
    servers to synch the computer clocks. Is that wrong? They even give away
    s/w to do the synching. I will edit them out until I learn otherwise.



    > I see nothing in here that would prevent ntpd from working once you have
    > the correct port open.


    I can do

    /usr/sbin/ntpdate -du 0.pool.ntp.org

    from the command line and it works. However, if I do:

    /usr/sbin/ntpq -p

    I get:

    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    192.245.169.15 .PPS. 1 u 76 1024 1 123.394 8246.05
    0.002
    gatling.ikk.szt 195.111.99.186 2 u 105 1024 1 120.227 8239.82
    0.002
    raptor.tera-byt 132.163.4.101 2 u 88 1024 1 87.253 8238.11
    0.002
    time-a.nist.gov .ACTS. 1 u 87 1024 1 158.194 8318.57
    0.002
    time-b.nist.gov .ACTS. 1 u 83 1024 1 125.022 8299.00
    0.002

    which doesn't show a default with an asterisk which somebody said would
    indicate the system used by ntpd to set the time automatically and keep
    it synched. Is this true? How can I tell if ntpd is working and keeping
    the clock synched?

    The system s/w reports that ntpd is running, but if I run

    /sbin/service ntpd status

    The output is:

    ntpd dead but pid file exists

    which contradicts the system s/w.

    >
    >> restrict default nomodify notrap noquery

    >
    > This restriction line applies to all of your ntpd's "clients" and
    > "servers". There is no need to specify explicit per host / subnet
    > restrict lines unless you wish to modify this restriction.
    >
    > http://ntp.isc.org/Support/AccessRestrictions contains information about
    > setting your ntpd restrictions.
    >
    >> restrict 127.0.0.1
    >>
    >> # --- OUR TIMESERVERS -----
    >> server 0.pool.ntp.org
    >> server 1.pool.ntp.org
    >> server 2.pool.ntp.org

    >
    > If you append 'iburst' to these server lines you will speed up ntpd's
    > initial synchronization from ~8 minutes to ~20 seconds.


    Done - thanks

    >
    > These pool server hostnames can resolve to serves located anywhere in
    > the world. You may wish to restrict the pool to your geographic area.
    > Please see http://ntp.isc.org/pool for more information.
    >
    >> fudge 127.127.1.0 stratum 10


    Commented out above


    >
    >> driftfile /var/lib/ntp/drift
    >> broadcastdelay 0.008

    Commented out above


    >> keys /etc/ntp/keys

    Commented out above


    >> restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
    >> restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
    >> restrict 2.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery

    >

    Commented out above


    >
    >> server time
    >> restrict time mask 255.255.255.255 nomodify notrap noquery
    >> server time
    >> restrict time mask 255.255.255.255 nomodify notrap noquery

    >
    > What's the point of the previous 4 lines? Do you have access to an NTP
    > server named 'time.your.domain' ?


    Commented out above - those lines came with the file - don't know who
    put them in the file shipped with FC 5.

    >
    >> server time-a.nist.gov
    >> restrict time-a.nist.gov mask 255.255.255.255 nomodify notrap noquery
    >> server time-b.nist.gov
    >> restrict time-b.nist.gov mask 255.255.255.255 nomodify notrap noquery

    >
    > These are Stratum-1 servers. Please check the the Rules of Engagement
    > (http://ntp.isc.org/rules) and make sure that you meet the criteria for
    > the direct use of Stratum-1 time servers. Unless you are supporting a
    > large number of client systems you should be using Stratum-2 servers
    > (http://ntp.isc.org/s2) and/or the NTP Pool (http://ntp.isc.org/pool).


    Will comment them out. As I said above they were added by the system s/w
    when I added NIST to the servers following the NIST web site
    encouragement to do so.


    >
    > The comment about redundant restrictions also applies here.
    >


    Still not sure that ntpd is working and keeping the clock synched. As I
    asked above - how do I tell????

    Thanks for your advice - it is much appreciated.

    Terry


    --
    ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++
    ================================================== ====
    ************************************************** ****
    If you are always rushing towards the future,
    Then you never have any past.

    Terry Boldt
    ************************************************** ****
    Paraphrasing Ben Franklin:

    Those who sacrifice freedom for safety, have neither.

    The exact quote:

    They that can give up essential liberty to obtain a little
    temporary safety deserve neither liberty nor safety.
    Benjamin Franklin (1706 - 1790),
    US author, diplomat, inventor, physicist, politician, & printer
    Historical Review of Pennsylvania, 1759

    ************************************************** ****

  2. Re: Not able to connect

    terrypearl wrote:

    > Steve - I thank you for your time in replying. Hopefully I can get this
    > operational.
    >


    >
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    >
    > 192.245.169.15 .PPS. 1 u 76 1024 1 123.394 8246.05
    > 0.002
    > gatling.ikk.szt 195.111.99.186 2 u 105 1024 1 120.227 8239.82
    > 0.002
    > raptor.tera-byt 132.163.4.101 2 u 88 1024 1 87.253 8238.11
    > 0.002
    > time-a.nist.gov .ACTS. 1 u 87 1024 1 158.194 8318.57
    > 0.002
    > time-b.nist.gov .ACTS. 1 u 83 1024 1 125.022 8299.00
    > 0.002
    >
    > which doesn't show a default with an asterisk which somebody said would
    > indicate the system used by ntpd to set the time automatically and keep
    > it synched. Is this true? How can I tell if ntpd is working and keeping
    > the clock synched?


    You didn't wait nearly long enough between starting ntpd and running
    ntpq -p!! The banner shows that each server has responded only once.
    The poll interval seems rather high to say the least. Polling normally
    starts at 64 second intervals unless you tamper with the defaults for
    MINPOLL and MAXPOLL. Such tampering is NOT a good idea!!!

    Adding "iburst" to each of your server statements in ntp.conf should
    give you a much quicker startup. It causes the first eight request
    packets to be sent at two second intervals and gets the information
    necessary to start synchronizing your clock in about sixteen seconds
    instead of almost six minutes.

    When the number in the "reach" column reaches 377 you know that the
    server has responded to the last eight requests; it's an eight bit shift
    register and the display is in octal. Each response from a server
    shifts a one bit in from the right hand side. When a server fails to
    respond a zero is shifted in.

    So make the necessary changes to ntp.conf and restart ntpd. Wait four
    or five minutes and say "ntpq -p". You should then get a banner that
    shows 377 for all the servers, and one of them should be marked with an
    asterisk in column one. The asterisk indicates "selected as the
    synchronization source". From zero to three others may be marked with a
    plus sign. The plus sign indicates the server is a member of the
    "selection set" and is thus a candidate for selection as the
    synchronization source. Minus signs indicate rejected servers and an
    "X" indicates that the server is considered "insane"!

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2