Tricking NTP's driftfile - NTP

This is a discussion on Tricking NTP's driftfile - NTP ; System Information: ------------------- At work, I am configuring a system which consists of six servers (master, slave1, ... slave5) networked together but kept isolated from any external network. The ONLY time requirement is that all the systems have the same ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Tricking NTP's driftfile

  1. Tricking NTP's driftfile

    System Information:
    -------------------
    At work, I am configuring a system which consists of six servers (master,
    slave1, ... slave5) networked together but kept isolated from any external
    network.

    The ONLY time requirement is that all the systems have the same time, which does
    NOT need to be accurate, just consistent.

    All servers run RHEL4 and use ntp-4.2.0.a.20040617-6.el4.

    All systems: (all files owned by root unless specified)
    /etc/ntp.conf 644
    server 127.127.1.0
    server master # LINE NOT INCLUDED ON master
    driftfile /var/lib/ntp/drift
    broadcastdelay 0.08

    /etc/ntp 755
    /etc/ntp/keys 600: Only commented lines
    /etc/ntpservers 644: Default (redhat time servers)
    /etc/step-tickers 644: slave: master, master: empty
    /var/lib/ntp/drift 644 (ntp:ntp): 0.0

    Problem:
    --------
    While the master goes through its synchronization routine (~10 mins), the slaves
    cannot obtain the time (see below). Even after the master is responsive, the
    drift file is not written to.
    [root@slave1 ~]# ntpdate -d master
    ....
    192.168.1.1: Server dropped: strata too high
    ....
    23 Jun 17:28:33 ntpdate [3343]: no server suitable for synchronization found

    Question:
    ---------
    I have tried adjusting the driftfile manually, and /var/log/messages shows the
    following:
    frequency initialized 0.001 PPM from /var/lib/ntp/drift

    However, the synchronization routine still runs.

    How do I 'trick' ntpd into thinking it has already performed the synchronization
    therefore not completing the routine?

  2. Re: Tricking NTP's driftfile


    [demime 1.01d removed an attachment of type multipart/signed]

  3. Re: Tricking NTP's driftfile

    In article <1214259078.48601f86a06d7@webmail.vt.edu>,
    Steven wrote:
    >System Information:
    >-------------------
    >At work, I am configuring a system which consists of six servers (master,
    >slave1, ... slave5) networked together but kept isolated from any external
    >network.
    >
    >The ONLY time requirement is that all the systems have the same time,
    >which does NOT need to be accurate, just consistent.
    >
    >All servers run RHEL4 and use ntp-4.2.0.a.20040617-6.el4.
    >
    >All systems: (all files owned by root unless specified)
    > /etc/ntp.conf 644
    > server 127.127.1.0
    > server master # LINE NOT INCLUDED ON master
    > driftfile /var/lib/ntp/drift
    > broadcastdelay 0.08
    >
    > /etc/ntp 755
    > /etc/ntp/keys 600: Only commented lines
    > /etc/ntpservers 644: Default (redhat time servers)
    > /etc/step-tickers 644: slave: master, master: empty
    > /var/lib/ntp/drift 644 (ntp:ntp): 0.0
    >
    >Problem:
    >--------
    >While the master goes through its synchronization routine (~10 mins), the slaves
    >cannot obtain the time (see below). Even after the master is responsive, the
    >drift file is not written to.
    >[root@slave1 ~]# ntpdate -d master
    >...
    >192.168.1.1: Server dropped: strata too high
    >...
    >23 Jun 17:28:33 ntpdate [3343]: no server suitable for synchronization found
    >
    >Question:
    >---------
    >I have tried adjusting the driftfile manually, and /var/log/messages shows the
    >following:
    >frequency initialized 0.001 PPM from /var/lib/ntp/drift
    >
    >However, the synchronization routine still runs.
    >
    >How do I 'trick' ntpd into thinking it has already performed the synchronization
    >therefore not completing the routine?


    You can't "trick" the server into not doing it's initial startup synchronization
    and the presence of a drift file simply gives NTP a starting point so that if
    you have an external time reference it will converge to that reference sooner.

    However, what you can do is significatly reduce the amount of time that NTP
    will take before it considers itself to be synchronized.

    I'd recommend replacing the following line on your master

    server 127.127.1.0

    with these 2 lines:

    server 127.127.1.0 minpoll 4 maxpoll 10
    fudge 127.127.1.1 stratum 10

    This will cause the NTP server to check itself every 16 seconds
    instead of the default 64 seconds. And then for the slave servers,
    I'd suggest that

    server 127.127.1.0

    Also be replaced with

    server 127.127.1.0
    fudge 127.127.1.1 stratum 12

    If you want, you could also use the minpoll and maxpoll options on the slaves
    as well. The importaint difference is upping the stratum 2 levels above
    what the master is set to.


  4. Re: Tricking NTP's driftfile

    On 2008-06-23, Steven wrote:

    > At work, I am configuring a system which consists of six servers
    > (master, slave1, ... slave5) networked together but kept isolated from
    > any external network.
    >
    > The ONLY time requirement is that all the systems have the same time,
    > which does NOT need to be accurate, just consistent.


    NTP synchronizes clocks to a common time base across a LAN / WAN. UTC
    is the most common time base; it's ubiquitous and relatively
    inexpensive. A useful side effect of using UTC as a time base is that
    the clocks are synchronized to the correct time.

    NTP needs a time base so that there is a target towards which to steer
    the clocks. The better the time base, the more stable and consistant the
    clocks will be. Without a time base ntpd can do little more than act as
    a glorified rdate.

    If all you want to do is (periodically) set the clocks to some common
    time, you might as well use rdate or timed.

    BTW: A ~$70 timing GPS (Garmin GPS-18LVC) can add great stability and
    consistancy to your time island.

    > All systems: (all files owned by root unless specified)
    > /etc/ntp.conf 644
    > server 127.127.1.0


    The only ntpd which should used the Undisciplined Local Clock is the one
    that you have chosen as a master. Append 'minpoll 4 maxpoll 4' to reduce
    the server's "self-sync time" to a bit under 60 seconds.

    > server master # LINE NOT INCLUDED ON master


    You should append 'iburst' to this server line to speed up the client
    sync from ~5 minutes to ~20 seconds (after the server becomes
    available.)

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


    The broadcastdelay line is only useful for an ntpd that is a
    broadcastclient. An ntpd in a unicast associatiion calculates the delay
    at each poll.

    > While the master goes through its synchronization routine (~10 mins), the slaves
    > cannot obtain the time (see below).


    If you use 'minpoll 4 maxpoll 4' as suggested above the server's initial
    "self-sync time" is a bit under 60 seconds.

    > Even after the master is responsive, the drift file is not written to.


    The drift file contains the frequency correction that ntpd needs to apply
    to the clock. Without a timebase ntpd has no reference to use to
    calculate the frequency correction.

    If you must use NTP in this time island, you should temporarily provide
    the server with some real time sources for at least an hour; it will
    take that long for the drift.file to be populated. This will provide
    ntpd some information about how to control the server's clock.

    > How do I 'trick' ntpd into thinking it has already performed the synchronization
    > therefore not completing the routine?


    Use 'minpoll 4 maxpoll 4' on the server as documented above to speed up
    the intial "self-sync time". Or switch to the current ntp-dev which,
    IIRC, "syncs" immediately to the Undisciplined Local Clock.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  5. Re: Tricking NTP's driftfile

    On 2008-06-24, J. Cochran wrote:
    > Steven wrote:


    > And then for the slave servers,
    > I'd suggest that
    >
    > server 127.127.1.0
    >
    > Also be replaced with
    >
    > server 127.127.1.0
    > fudge 127.127.1.1 stratum 12


    The Undisciplined Local Clock contributes nothing the quality of the
    client systems' clocks and, in fact, can cause problems if
    misconfigured.

    The Undisciplined Local Clock is _not_ a "back-up"; it is merely a hack
    which allows an ntpd to pretend to be synced even when no real time
    sources are reachable.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  6. Re: Tricking NTP's driftfile

    Steven wrote:
    []
    > Problem:
    > --------
    > While the master goes through its synchronization routine (~10 mins),
    > the slaves cannot obtain the time (see below). Even after the master
    > is responsive, the drift file is not written to.

    []
    > How do I 'trick' ntpd into thinking it has already performed the
    > synchronization therefore not completing the routine?


    Why does the master take that long? If you are using iburst on the server
    lines it should be much faster.

    IIRC, the drift file is only written hourly.

    Does that help?

    Cheers,
    David



  7. Re: Tricking NTP's driftfile

    In article ,
    Steve Kostecke wrote:
    >On 2008-06-24, J. Cochran wrote:
    >> Steven wrote:

    >
    >> And then for the slave servers,
    >> I'd suggest that
    >>
    >> server 127.127.1.0
    >>
    >> Also be replaced with
    >>
    >> server 127.127.1.0
    >> fudge 127.127.1.1 stratum 12

    >
    >The Undisciplined Local Clock contributes nothing the quality of the
    >client systems' clocks and, in fact, can cause problems if
    >misconfigured.
    >
    >The Undisciplined Local Clock is _not_ a "back-up"; it is merely a hack
    >which allows an ntpd to pretend to be synced even when no real time
    >sources are reachable.


    I know that, you know that. But in the OPs case, he really isn't
    concerned with having accurate time that's attributable to an authorative
    source. He merely wants an isolated network of several macros to all
    have a consistent time between them. You may have noticed that he's
    *already* using an undiscoplined local clock. My suggestion is to
    simply reduce the polling time to reduce his initial startup time
    (which he's complaining about) and to fudge the stratum to a high enough
    number that *if* for some reason his unconnected network finds itself
    on the public internet, then no one will accidently use him as a time
    reference. Yet, a low enough stratum that he's not going to have issues
    with exceeding stratum 15.

    Yes, making a recommendation to the OP that he should get a couple
    of GPS receivers (the Garmen 18 LVC is a nice one) and that he should
    then use the PPS interface, etc., etc., etc. to make a NTP server that's
    accurate to within a few micro seconds and is attributable to a
    national time standard would also solve his problem. However, given
    his requirements, it would be more than a little overkill.

  8. Re: Tricking NTP's driftfile

    On 2008-06-24, David J Taylor wrote:
    > Steven wrote:


    >> While the master goes through its synchronization routine (~10 mins),
    >> the slaves cannot obtain the time (see below). Even after the master
    >> is responsive, the drift file is not written to.

    >
    > Why does the master take that long?


    Using the current stable release of NTP (4.2.4) the Undisciplined Local
    Clock syncs after 4 "polls". The first "poll" occurs shortly after ntpd
    starts; let's say at ~ 10 seconds. The next three polls occur at
    minpoll. So with the default poll of 64 seconds ntpd needs:

    10+(3*64) or ~ 202 seconds or ~ 3 min 22 seconds to declare the
    Undisciplined Local Clock to be "synced".

    If minpoll is reduced to 16 seconds (minpoll 4) the Undisciplined Local
    CLock "sync time" is:

    10+(3*10) or ~ 40 seconds

    IIRC recent NTP-dev releases now immediately "sync" to the Undisciplined
    Local Clock at startup.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  9. Re: Tricking NTP's driftfile

    On 2008-06-24, J. Cochran wrote:

    > Steve Kostecke wrote:
    >
    >>On 2008-06-24, J. Cochran wrote:
    >>
    >>> Steven wrote:

    >>
    >>> And then for the slave servers, I'd suggest that server 127.127.1.0
    >>> Also be replaced with fudge 127.127.1.1 stratum 12

    >>
    >>The Undisciplined Local Clock contributes nothing the quality of
    >>the client systems' clocks and, in fact, can cause problems if
    >>misconfigured.
    >>
    >>The Undisciplined Local Clock is _not_ a "back-up"; it is merely a
    >>hack which allows an ntpd to pretend to be synced even when no real
    >>time sources are reachable.

    >
    > I know that, you know that.


    There is no reason to use the Undisciplined Local Clock on a leaf node.
    None.

    > But in the OPs case, he really isn't concerned with having accurate
    > time that's attributable to an authorative source.


    The OP has demonstrated a classic misunderstanding of how NTP works.

    > He merely wants an isolated network of several macros to all have a
    > consistent time between them.


    NTP is overkill for this application.

    > You may have noticed that he's *already* using an undiscoplined local
    > clock.


    I noticed that the OP is using the Undisciplined Local Clock on all
    nodes (both master and slave) on his time island. This observation is
    what led to my reply to your article.

    The fact is that the Undisciplined Local Clock does only _one_ thing: it
    allows ntpd to serve time to others even when it is not synced to a real
    time source. That's all. The Undiscplined Local Clock does not provide
    any sort of time base, or other sync information, to ntpd.

    > My suggestion is to simply reduce the polling time to reduce
    > his initial startup time (which he's complaining about)


    You're not the only person who has suggested this.

    > and to fudge the stratum to a high enough number that *if* for some
    > reason his unconnected network finds itself on the public internet,
    > then no one will accidently use him as a time reference. Yet, a low
    > enough stratum that he's not going to have issues with exceeding
    > stratum 15.


    The default stratum for the Undisciplined Local Clock is 5.

    > Yes, making a recommendation to the OP that he should get a couple of
    > GPS receivers (the Garmen 18 LVC is a nice one)


    Please re-read my original article. I suggested _one_ GPS for his
    "master" server.

    > and that he should then use the PPS interface, etc., etc., etc. to
    > make a NTP server that's accurate to within a few micro seconds and is
    > attributable to a national time standard would also solve his problem.


    You have missed the point.

    This is not an issue of using a time source traceable to a national
    standards laboratory. It _is_ a matter of providing ntpd with a stable
    time base.

    > However, given his requirements, it would be more than a little
    > overkill.


    Given the OP's requirements, anything beyond rdate is overkill.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  10. Re: Tricking NTP's driftfile

    Steve Kostecke wrote:
    > On 2008-06-24, David J Taylor wrote:
    >> Steven wrote:

    >
    >>> While the master goes through its synchronization routine (~10
    >>> mins), the slaves cannot obtain the time (see below). Even after
    >>> the master is responsive, the drift file is not written to.

    >>
    >> Why does the master take that long?

    >

    []
    > IIRC recent NTP-dev releases now immediately "sync" to the
    > Undisciplined Local Clock at startup.


    Steve,

    Thanks for that - I missed that the OP wasn't using a reference clock or
    Internet servers! As others have suggested, I commend the Garmin GPS18
    LVC as an easy to use reference clock.

    Cheers,
    David



  11. Re: Tricking NTP's driftfile

    Steve,

    In the current development version reference clocks are reachable on the
    first poll. The preferred orphan mode is available intantly. The releasr
    version tends to lag the development version by some time; however, the
    design where refclocks are reachable on the first poll has been active
    for quite some time.

    Dave

    Steve Kostecke wrote:
    > On 2008-06-24, David J Taylor wrote:
    >
    >>Steven wrote:

    >
    >
    >>>While the master goes through its synchronization routine (~10 mins),
    >>>the slaves cannot obtain the time (see below). Even after the master
    >>>is responsive, the drift file is not written to.

    >>
    >>Why does the master take that long?

    >
    >
    > Using the current stable release of NTP (4.2.4) the Undisciplined Local
    > Clock syncs after 4 "polls". The first "poll" occurs shortly after ntpd
    > starts; let's say at ~ 10 seconds. The next three polls occur at
    > minpoll. So with the default poll of 64 seconds ntpd needs:
    >
    > 10+(3*64) or ~ 202 seconds or ~ 3 min 22 seconds to declare the
    > Undisciplined Local Clock to be "synced".
    >
    > If minpoll is reduced to 16 seconds (minpoll 4) the Undisciplined Local
    > CLock "sync time" is:
    >
    > 10+(3*10) or ~ 40 seconds
    >
    > IIRC recent NTP-dev releases now immediately "sync" to the Undisciplined
    > Local Clock at startup.
    >


+ Reply to Thread