NTPD sync now - NTP

This is a discussion on NTPD sync now - NTP ; I'm setting up PC1 (W2K) as an NTP server for 1 local machine PC2 which does not have internet access. NTP software from http://www.meinberg.de/english/sw/ntp.htm installed and working on PC1 w32time service is stopped and disabled. PC1 ntp.conf: driftfile "C:\Program Files\NTP\etc\ntp.drift" ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: NTPD sync now

  1. NTPD sync now

    I'm setting up PC1 (W2K) as an NTP server for 1 local machine PC2 which
    does not have internet access.

    NTP software from http://www.meinberg.de/english/sw/ntp.htm installed
    and working on PC1
    w32time service is stopped and disabled.

    PC1 ntp.conf:
    driftfile "C:\Program Files\NTP\etc\ntp.drift"
    logfile "C:\Program Files\NTP\etc\ntp.log"
    fudge 127.127.1.0 stratum 10
    server msltime.irl.cri.nz

    Whenever I stop and start the NTP service on PC1, I have to wait 5
    minutes before PC1 will report the following in the log and start
    acting as an NTP server.
    PC1 ntp.log:
    1 Nov 12:00:00 ntpd.exe[1792]: The Network Time Protocol Service has
    stopped.
    1 Nov 12:04:14 ntpd.exe[164]: synchronized to 131.203.16.6, stratum 1

    Question: After I start the NTP service, is there a way to give NTP a
    kick to that it synchronises with the internet NTP server immediately,
    so I don't have to wait for 5 minutes? ie a "Sync Now" command using
    something like NTPQ.

    Thanks
    Nick


  2. Re: NTPD sync now


    nicough@gmail.com wrote:
    > I'm setting up PC1 (W2K) as an NTP server for 1 local machine PC2 which
    > does not have internet access.
    >
    > NTP software from http://www.meinberg.de/english/sw/ntp.htm installed
    > and working on PC1
    > w32time service is stopped and disabled.
    >
    > PC1 ntp.conf:
    > driftfile "C:\Program Files\NTP\etc\ntp.drift"
    > logfile "C:\Program Files\NTP\etc\ntp.log"
    > fudge 127.127.1.0 stratum 10
    > server msltime.irl.cri.nz
    >
    > Whenever I stop and start the NTP service on PC1, I have to wait 5
    > minutes before PC1 will report the following in the log and start
    > acting as an NTP server.
    > PC1 ntp.log:
    > 1 Nov 12:00:00 ntpd.exe[1792]: The Network Time Protocol Service has
    > stopped.
    > 1 Nov 12:04:14 ntpd.exe[164]: synchronized to 131.203.16.6, stratum 1
    >
    > Question: After I start the NTP service, is there a way to give NTP a
    > kick to that it synchronises with the internet NTP server immediately,
    > so I don't have to wait for 5 minutes? ie a "Sync Now" command using
    > something like NTPQ.
    >
    > Thanks
    > Nick


    Nick,
    Add the 'iburst' keyword after your server statement like:

    server msltime.irl.cri.nz iburst

    Also, depending on DNS lookup may delay things. Consider using IP
    address instead.

    Probably be a good idea to add a few more sources as well, although
    that won't necessarily make it any faster. iburst is the win here.

    Roger


  3. Re: NTPD sync now

    I don't know about windows, (it should be the same as unix), but if you can
    get 'iburst' into the ntp.conf file and have a good drift file you should
    achieve sync in about 11 seconds' time.

    H

  4. Re: NTPD sync now

    Harlan Stenn wrote:
    > I don't know about windows, (it should be the same as unix), but if
    > you can get 'iburst' into the ntp.conf file and have a good drift
    > file you should achieve sync in about 11 seconds' time.
    >
    > H


    Yes, the Windows port accepts "iburst" and acts on it.

    As Roger said, you should also add some more servers, making the total
    perhaps four or five. There is a list here:

    http://ntp.isc.org/bin/view/Servers/WebHome

    Try to choose servers to which you have a short network path.

    David



  5. Re: NTPD sync now

    iburst worked perfectly thanks.
    Nick


  6. Re: NTPD sync now

    Hi,

    A question in this context:

    Is there a good way to tell ntpd to
    connect to upstream time servers "now".

    context:
    machine on remote site sitting behind an
    ISDN dial on demand line to the main network.

    Timeserver there is well managed.

    The connection is active on a regular basis
    but ntpd connnects regularly happen in inactive
    times ( dial delay, extra cost, ... ).

    G!
    uwe

  7. Re: NTPD sync now

    Uwe,

    There are a couple of ways to go for this case.

    - set maxpoll to be some number that will insure at least a couple of
    "associations" at least once or twice a day

    - use the ppp.{up,down} scripts to bring up/tear down your associations
    and be sure to use iburst in your config file.

    H
    --
    >>> In article <358m14-tre.ln1@robert.houseofmax.de>, Uwe Klein writes:


    Uwe> Is there a good way to tell ntpd to connect to upstream time servers
    Uwe> "now".

    Uwe> context: machine on remote site sitting behind an ISDN dial on demand
    Uwe> line to the main network.

    Uwe> Timeserver there is well managed.

    Uwe> The connection is active on a regular basis but ntpd connnects
    Uwe> regularly happen in inactive times ( dial delay, extra cost, ... ).

  8. Re: NTPD sync now

    Harlan Stenn wrote:
    > Uwe,
    >

    Hey Harlan,
    Thanks for your answer,
    > There are a couple of ways to go for this case.
    >
    > - set maxpoll to be some number that will insure at least a couple of
    > "associations" at least once or twice a day
    >
    > - use the ppp.{up,down} scripts to bring up/tear down your associations
    > and be sure to use iburst in your config file.

    the dialing cisco box is separate. I do get its logging stream as input to
    syslog though and use it for accounting and other stuff.

    i have this in my ntp.conf:
    server 172.30.24.1 iburst minpoll 10 maxpoll 16

    ppp_{up,down}
    The default setup from SuSE does it that way. i.e. a hard restart through
    "rcntpd restart" to handle changed IP on interface changes.

    But isn't that rather "unelegant"? Doesn't ntpd loose info through a restart?

    your idea was to use ntpdc to fix "maxpoll" up and down ?

    wouldn't something like "pollnow [hostip] " as cmd to ntpdc be usefull?

    uwe

    >>>>In article <358m14-tre.ln1@robert.houseofmax.de>, Uwe Klein writes:

    >
    >
    > Uwe> Is there a good way to tell ntpd to connect to upstream time servers
    > Uwe> "now".
    >
    > Uwe> context: machine on remote site sitting behind an ISDN dial on demand
    > Uwe> line to the main network.
    >
    > Uwe> Timeserver there is well managed.
    >
    > Uwe> The connection is active on a regular basis but ntpd connnects
    > Uwe> regularly happen in inactive times ( dial delay, extra cost, ... ).


  9. Re: NTPD sync now

    Uwe,

    If your cisco box is the gateway then I think a good way to go is to figure
    out the minimum amount of time the connection will be up and make sure your
    poll interval is not significantly greater than this amount of time.

    If it is "just less than" this amount of time, you should be getting a
    "volley" between your server and the outside once per call.

    If you are serving multiple hosts, then consider running a local refclock on
    this one machine, so everybody will stay in sync in between phone calls.

    H

  10. Re: NTPD sync now

    Harlan Stenn wrote:
    > Uwe,
    >
    > If your cisco box is the gateway then I think a good way to go is to figure
    > out the minimum amount of time the connection will be up and make sure your
    > poll interval is not significantly greater than this amount of time.


    This does imho not work the way you think or as i understand it.

    every time a poll to the upstream server is tried the dialup box will start
    dialing ( 1/2 sec delay ) and then the connection will be up for the
    idle_timeout time ~30sec.

    Data File changes are every 30 minutes on 0/30, There is some postprocessing
    delay ~(5 minutes)
    Regular connection traffic is per pull from outside every 30minutes 9/39 for
    most of the day ( ~sunup till sundown+something , actually a bit less as i can
    not dip most antenna dished to look onto the horizon only 10/20 deg above that)

    what irks me is that ntp allways creates extra slots in between.

    >
    > If it is "just less than" this amount of time, you should be getting a
    > "volley" between your server and the outside once per call.
    >
    > If you are serving multiple hosts, then consider running a local refclock on
    > this one machine, so everybody will stay in sync in between phone calls.
    >
    > H

    uwe


  11. Re: NTPD sync now

    In article <3ltp14-tse.ln1@robert.houseofmax.de>,
    Uwe Klein wrote:

    > what irks me is that ntp allways creates extra slots in between.


    That's a problem with your demand dial software. You should use software
    that you can configure to transmit NTP when the link is up but not bring
    it up for NTP, nor keep it up for NTP. (Good demand dial software will
    also do things like varying the timeout depending on the type of packet
    and whether there are open TCP connections.)

    Alternatively, you can, but only after getting explicit permission
    from the people who operate your servers (you will probably find this
    limits you to your ISP and your own company), use the burst option,
    which should try enough polls with enough gaps to ensure that the later
    polls get through. Using burst without permission is considered as
    serious abuse and may get you blocked by the server.

    Generally, though, ntpd and demand dial don't go together particularly
    well.


  12. Re: NTPD sync now

    Guys,

    In a lot of telcos today long distance dialing is free or almost free.
    You might consider ACTS/USNO as I do in my campus office. The ntpd calls
    every 36 hours and keeps the clock generally within 50 ms.

    The expectation in the ntpd design is that the router, upon receiving a
    NTP packet, would initiate the ISP lease, burst eight packets, update
    the clock and expect the router to time out the call. The burst program
    can be tinkered for an initial poll interval whatever it takes for the
    line to become hot, then finish up at two-second intervals. Clever
    adjustments for minpoll, maxpoll and the router timeout should cover
    most cases.

    Dave

    David Woolley wrote:
    > In article <3ltp14-tse.ln1@robert.houseofmax.de>,
    > Uwe Klein wrote:
    >
    >
    >>what irks me is that ntp allways creates extra slots in between.

    >
    >
    > That's a problem with your demand dial software. You should use software
    > that you can configure to transmit NTP when the link is up but not bring
    > it up for NTP, nor keep it up for NTP. (Good demand dial software will
    > also do things like varying the timeout depending on the type of packet
    > and whether there are open TCP connections.)
    >
    > Alternatively, you can, but only after getting explicit permission
    > from the people who operate your servers (you will probably find this
    > limits you to your ISP and your own company), use the burst option,
    > which should try enough polls with enough gaps to ensure that the later
    > polls get through. Using burst without permission is considered as
    > serious abuse and may get you blocked by the server.
    >
    > Generally, though, ntpd and demand dial don't go together particularly
    > well.
    >


  13. Re: NTPD sync now

    David Woolley wrote:
    > In article <3ltp14-tse.ln1@robert.houseofmax.de>,
    > Uwe Klein wrote:
    >
    >
    >>what irks me is that ntp allways creates extra slots in between.

    >
    >
    > That's a problem with your demand dial software. You should use software
    > that you can configure to transmit NTP when the link is up but not bring
    > it up for NTP, nor keep it up for NTP. (Good demand dial software will
    > also do things like varying the timeout depending on the type of packet
    > and whether there are open TCP connections.)

    I am well aware what i can do with proper software be it router, dialer,
    firewall or whatnot.
    But your idea proposes a trail of blood and splatter all the way to
    the next server.

    In my case i would even be able to manhandle the guy who has to maintain
    this cisco router box to accomodate me. But it is extra effort that
    entails the requirement for further maintainance at places where influence
    or contact may be low.

    Actually something like that reqularly evolves into a nightmare.
    There is a recurring problem with requirering the mountain come to the prophet ;-)

    The internet has changed to a mobile and not permanently connected world.
    The times of wellkept expensive boxes in a static configuration are long gone.

    To have better control on ntpd connection behaviour would be a boon and
    imho enable some very interesting apps using it.

    uwe

  14. Re: NTPD sync now

    Uwe Klein wrote:
    []
    > The internet has changed to a mobile and not permanently connected
    > world. The times of wellkept expensive boxes in a static configuration
    > are
    > long gone.
    > To have better control on ntpd connection behaviour would be a boon
    > and imho enable some very interesting apps using it.
    >
    > uwe


    Other time keeping applications (e.g. Tardis) which use the (S)NTP
    protocol appear to detect dial-up connections starting, so it's certainly
    possible. I agree that it would be a worthwhile addition to NTP's feature
    set.

    David



+ Reply to Thread