limitation on the client time/date at ntp startup - NTP

This is a discussion on limitation on the client time/date at ntp startup - NTP ; What is the limitation on the time difference of a client clock at ntp startup? Is it 1000 sec? Is there an option to increase this or a 'commercial' version of NTP that will allow greater differences? e.g. years I ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: limitation on the client time/date at ntp startup

  1. limitation on the client time/date at ntp startup

    What is the limitation on the time difference of a client clock at ntp
    startup? Is it 1000 sec? Is there an option to increase this or a
    'commercial' version of NTP that will allow greater differences? e.g.
    years

    I have a local network set up with a GPS connected to one pc acting as
    a ntp server. The GPS synchronizes the system clock of this pc. NTP
    distributes the time to another pc on the network. It appears that I
    can not change the client pc time/date more than 1000 sec or ntp will
    not correct the client clock.

    thank you


  2. Re: limitation on the client time/date at ntp startup

    BG wrote:

    > What is the limitation on the time difference of a client clock at ntp
    > startup? Is it 1000 sec? Is there an option to increase this or a
    > 'commercial' version of NTP that will allow greater differences? e.g.
    > years
    >
    > I have a local network set up with a GPS connected to one pc acting as
    > a ntp server. The GPS synchronizes the system clock of this pc. NTP
    > distributes the time to another pc on the network. It appears that I
    > can not change the client pc time/date more than 1000 sec or ntp will
    > not correct the client clock.
    >
    > thank you
    >


    Then don't change the time on the client!!! This is a non-issue in a
    properly configure NTP network.

    The limit is 1024 seconds and I doubt that anyone is willing to change
    it. You can start ntpd on the client with the -g option and it will set
    the client's clock on a one time basis. Thereafter, ntpd should be able
    to keep it synchronized. If not, there is something very wrong with,
    most probably, the client or (barely possible) the server.

    When ntpd is synchronizing the client, no one should be trying to change
    the client's clock!!!


  3. Re: limitation on the client time/date at ntp startup

    Thank you. The reason I need to change the client clock is to 'prove'
    to skeptics that it is working.

    B Gillcrist


    Richard B. Gilbert wrote:
    > BG wrote:
    >
    > > What is the limitation on the time difference of a client clock at ntp
    > > startup? Is it 1000 sec? Is there an option to increase this or a
    > > 'commercial' version of NTP that will allow greater differences? e.g.
    > > years
    > >
    > > I have a local network set up with a GPS connected to one pc acting as
    > > a ntp server. The GPS synchronizes the system clock of this pc. NTP
    > > distributes the time to another pc on the network. It appears that I
    > > can not change the client pc time/date more than 1000 sec or ntp will
    > > not correct the client clock.
    > >
    > > thank you
    > >

    >
    > Then don't change the time on the client!!! This is a non-issue in a
    > properly configure NTP network.
    >
    > The limit is 1024 seconds and I doubt that anyone is willing to change
    > it. You can start ntpd on the client with the -g option and it will set
    > the client's clock on a one time basis. Thereafter, ntpd should be able
    > to keep it synchronized. If not, there is something very wrong with,
    > most probably, the client or (barely possible) the server.
    >
    > When ntpd is synchronizing the client, no one should be trying to change
    > the client's clock!!!



  4. Re: limitation on the client time/date at ntp startup

    I can get ntp to run by typing in ntpd -n -g in a console window but
    for this application I don't want to keep a console window visible. Is
    there a way to automatically start ntp with the options and you see the
    service running in the services window?


    Richard B. Gilbert wrote:
    > BG wrote:
    >
    > > What is the limitation on the time difference of a client clock at ntp
    > > startup? Is it 1000 sec? Is there an option to increase this or a
    > > 'commercial' version of NTP that will allow greater differences? e.g.
    > > years
    > >
    > > I have a local network set up with a GPS connected to one pc acting as
    > > a ntp server. The GPS synchronizes the system clock of this pc. NTP
    > > distributes the time to another pc on the network. It appears that I
    > > can not change the client pc time/date more than 1000 sec or ntp will
    > > not correct the client clock.
    > >
    > > thank you
    > >

    >
    > Then don't change the time on the client!!! This is a non-issue in a
    > properly configure NTP network.
    >
    > The limit is 1024 seconds and I doubt that anyone is willing to change
    > it. You can start ntpd on the client with the -g option and it will set
    > the client's clock on a one time basis. Thereafter, ntpd should be able
    > to keep it synchronized. If not, there is something very wrong with,
    > most probably, the client or (barely possible) the server.
    >
    > When ntpd is synchronizing the client, no one should be trying to change
    > the client's clock!!!



  5. Re: limitation on the client time/date at ntp startup

    BG wrote:
    > I can get ntp to run by typing in ntpd -n -g in a console window but
    > for this application I don't want to keep a console window visible. Is
    > there a way to automatically start ntp with the options and you see the
    > service running in the services window?
    >


    In just about any environment but Windoze, it's not difficult. System
    startup runs a script that starts ntpd with options. You could try
    autoexec.bat but I have serious doubts that it would work as you hope.
    It would start ntpd with command line options but probably far too early
    for the TCP/IP stack to be up and running. So ntpd fails to resolve the
    IP addresses of the servers or something.

    I don't use ntpd on Windoze; w32time keeps the clock close enough for
    govenment work.

  6. Re: limitation on the client time/date at ntpstartup

    BG wrote:
    > I can get ntp to run by typing in ntpd -n -g in a console window but
    > for this application I don't want to keep a console window visible. Is
    > there a way to automatically start ntp with the options and you see the
    > service running in the services window?
    >


    Assuming you are talking about windows, yes. You didn't say what version
    you are using. The newer versions, such as 4.2.2, support this in the
    imagepath for the service just by adding the command line options.

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


  7. Re: limitation on the client time/date at ntp startup

    BG wrote:
    > I can get ntp to run by typing in ntpd -n -g in a console window but
    > for this application I don't want to keep a console window visible. Is
    > there a way to automatically start ntp with the options and you see the
    > service running in the services window?
    >



    Our current Windows NTP installer (free) is capable of using the "-g"
    option (the corresponding installer checkbox is labelled "allow big
    initial timesteps"). But -g works only once, at startup. If you want to
    show that you can change the time to 2003 and it is corrected
    automagically, this won't work (ntp will exit and you have to restart it
    yourself, losing all that "automagic" ...).

    If you combine it with our free NTP Time Monitor - which can be set up
    to automatically restart NTP in case it dies - your problem would be solved.

    For your presentation I would use ntpdate and let it run once a minute
    using the task scheduler of Windows ... :-)

    Best regards,
    Heiko



    >
    > Richard B. Gilbert wrote:
    >> BG wrote:
    >>
    >>> What is the limitation on the time difference of a client clock at ntp
    >>> startup? Is it 1000 sec? Is there an option to increase this or a
    >>> 'commercial' version of NTP that will allow greater differences? e.g.
    >>> years
    >>>
    >>> I have a local network set up with a GPS connected to one pc acting as
    >>> a ntp server. The GPS synchronizes the system clock of this pc. NTP
    >>> distributes the time to another pc on the network. It appears that I
    >>> can not change the client pc time/date more than 1000 sec or ntp will
    >>> not correct the client clock.
    >>>
    >>> thank you
    >>>

    >> Then don't change the time on the client!!! This is a non-issue in a
    >> properly configure NTP network.
    >>
    >> The limit is 1024 seconds and I doubt that anyone is willing to change
    >> it. You can start ntpd on the client with the -g option and it will set
    >> the client's clock on a one time basis. Thereafter, ntpd should be able
    >> to keep it synchronized. If not, there is something very wrong with,
    >> most probably, the client or (barely possible) the server.
    >>
    >> When ntpd is synchronizing the client, no one should be trying to change
    >> the client's clock!!!

    >


  8. Re: limitation on the client time/date at ntp startup

    In article <1156282058.994857.239810@p79g2000cwp.googlegroups. com>,
    "BG" wrote:

    > Thank you. The reason I need to change the client clock is to 'prove'
    > to skeptics that it is working.


    But it doesn't prove that it is working. All it demonstrates is
    an error recovery path, working at a precision that could be achieved
    using very crude time synchronisation protocols, is working. If you
    really want to demonstrate that ntpd is working, you would need to do
    something like heating or cooling the crystal oscillator on the
    motherboard (assuming you are in an air conditioned room and can't
    do this for the whole machine) and demonstrate that the frequency error
    is compensated correctly.

    In reality, ntpd has no need to be able to handle errors of more than
    about 30 seconds, as that is about the maximum error in a watch used to
    set the initial time.

    > BG wrote:
    >
    > > What is the limitation on the time difference of a client clock at ntp
    > > startup? Is it 1000 sec? Is there an option to increase this or a


    It's unlimited if you use the -g option, but only for the first
    correction.

    > > 'commercial' version of NTP that will allow greater differences? e.g.
    > > years


    The reference version is much easier to change in this respect than any
    commercial version, as you can just change the limit constant in the
    source code. You don't even need to change the source code, as there is
    a tinker option documented that allows you to change or disable this
    check.

    However, make sure that you change it back after the admirals
    have left.

    > > distributes the time to another pc on the network. It appears that I
    > > can not change the client pc time/date more than 1000 sec or ntp will
    > > not correct the client clock.


    This is not startup, though.

  9. Re: limitation on the client time/date at ntp startup

    David,

    Classic way to test NTP functionality is to stop ntpd, set the time by
    some other means within 68 years of the correct time, then start ntpd
    with -g.

    Dave

    David Woolley wrote:
    > In article <1156282058.994857.239810@p79g2000cwp.googlegroups. com>,
    > "BG" wrote:
    >
    >
    >>Thank you. The reason I need to change the client clock is to 'prove'
    >>to skeptics that it is working.

    >
    >
    > But it doesn't prove that it is working. All it demonstrates is
    > an error recovery path, working at a precision that could be achieved
    > using very crude time synchronisation protocols, is working. If you
    > really want to demonstrate that ntpd is working, you would need to do
    > something like heating or cooling the crystal oscillator on the
    > motherboard (assuming you are in an air conditioned room and can't
    > do this for the whole machine) and demonstrate that the frequency error
    > is compensated correctly.
    >
    > In reality, ntpd has no need to be able to handle errors of more than
    > about 30 seconds, as that is about the maximum error in a watch used to
    > set the initial time.
    >
    >
    >>BG wrote:
    >>
    >>
    >>>What is the limitation on the time difference of a client clock at ntp
    >>>startup? Is it 1000 sec? Is there an option to increase this or a

    >
    >
    > It's unlimited if you use the -g option, but only for the first
    > correction.
    >
    >
    >>>'commercial' version of NTP that will allow greater differences? e.g.
    >>>years

    >
    >
    > The reference version is much easier to change in this respect than any
    > commercial version, as you can just change the limit constant in the
    > source code. You don't even need to change the source code, as there is
    > a tinker option documented that allows you to change or disable this
    > check.
    >
    > However, make sure that you change it back after the admirals
    > have left.
    >
    >
    >>>distributes the time to another pc on the network. It appears that I
    >>>can not change the client pc time/date more than 1000 sec or ntp will
    >>>not correct the client clock.

    >
    >
    > This is not startup, though.


  10. Re: limitation on the client time/date at ntp startup

    In article ,
    David L. Mills wrote:

    > Classic way to test NTP functionality is to stop ntpd, set the time by


    This isn't a classic way because it hasn't been an available option for
    long enough. It's also not classic because it is not what people actually
    do; what they actually do is to change the time on a running client (or,
    if they are using an undisciplined local clock on the server, change the
    time on a running server).

    As I pointed out, it is also not a valid test because it fails to demonstrate
    the phase locked loop in ntpd, which is the main part of ntpd, except in as
    much that someone more knowldedgeable than the sort of person for which this
    sort of demonstration is done, may be able to see the final convergence onto
    the correct time and frequency.

    If you really think it is a good test, I'm surprised that you have let so
    many regulars here criticise people for doing these step change tests in the
    past.

    > some other means within 68 years of the correct time, then start ntpd
    > with -g.


  11. Re: limitation on the client time/date at ntp startup

    In article david@djwhome.demon.co.uk
    (David Woolley) writes:
    >In article ,
    >David L. Mills wrote:
    >
    >> Classic way to test NTP functionality is to stop ntpd, set the time by

    >
    >This isn't a classic way because it hasn't been an available option for
    >long enough.


    The option of stopping ntpd?:-) If you mean -g, I think it has been
    around since xntpd/v3 days, though possibly with slightly different
    semantics back then (I'm not sure if it was limited to *one* step).
    Note, I'm not saying it was *documented*.:-)

    --Per Hedeland
    per@hedeland.org

  12. Re: limitation on the client time/date at ntp startup

    David,

    I have no idea whatsoever what you are talking about. If you need to
    test whether the clock state machine correctly responds to large time
    offsets, then my suggested scheme is exactly what you need. I have
    tested every NTP version since 1982 in just that way, most recently to
    confirm the clock is set correctly after the 2036 roll.

    Using a large time step offset is not the way to test the PLL/FLL
    functionality, and I did not intend the "classic" scheme to test it thar
    way. The PLL/FLL loop is pseudo-linear and needs to be perturbed by a
    small offset less than the step threshold (128 ms). Either that or
    change the step threshold to something large and set the offset manually.

    I test by setting the frequency to something large, like 500 PPM and
    running the daemon (or kernel) for a few minutes in order to accumulate
    a modest error, like 100 ms. Then, restore the original frequency file
    or delete it, as required and restart the daemon. The intent is to
    confirm the zero crossing as the loop converges (about one hour) and to
    confirm the overshoot is modest (less than 6 percent). All this with a
    64-s poll interval.

    Your last comment is confusing. I have never criticized folks for doing
    tests involving step or linear adjustments. What I have done is question
    the wisdom of forcing the step threshold to very large values in order
    to insure monotonic adjustments. The reasons for this are explained in
    the white papers at the NTP project site.

    Dave

    David Woolley wrote:
    > In article ,
    > David L. Mills wrote:
    >
    >
    >>Classic way to test NTP functionality is to stop ntpd, set the time by

    >
    >
    > This isn't a classic way because it hasn't been an available option for
    > long enough. It's also not classic because it is not what people actually
    > do; what they actually do is to change the time on a running client (or,
    > if they are using an undisciplined local clock on the server, change the
    > time on a running server).
    >
    > As I pointed out, it is also not a valid test because it fails to demonstrate
    > the phase locked loop in ntpd, which is the main part of ntpd, except in as
    > much that someone more knowldedgeable than the sort of person for which this
    > sort of demonstration is done, may be able to see the final convergence onto
    > the correct time and frequency.
    >
    > If you really think it is a good test, I'm surprised that you have let so
    > many regulars here criticise people for doing these step change tests in the
    > past.
    >
    >
    >>some other means within 68 years of the correct time, then start ntpd
    >>with -g.



  13. Re: limitation on the client time/date at ntp startup

    Per,

    I may have to wash out my mouth with soap after telling you this.

    The xntp daemon maintained two timescales, one for the daemon and the
    other for the kernel. There could be a large discrepancy between these
    timescales that was not revealed by the monitoring functions. Secondly,
    late xntpd and and eraly ntpd used two independent loops, one for "slew"
    mode and the other for "normal" modes. This was a mistake; the slew is
    now incorporated in the normal model. The only difference is that slew
    normally means simply increasing the step threshold; the loop functions
    remain the same.

    Note that some systems, including Solaris, have modified the adjtime()
    syscall function to more quickly respond to large adjustments. This adds
    an extra poll to the feedback loop response. Setting a large step
    threshold can result in large overshoot and possible unstable behavior.

    Dave

    Per Hedeland wrote:

    > In article david@djwhome.demon.co.uk
    > (David Woolley) writes:
    >
    >>In article ,
    >>David L. Mills wrote:
    >>
    >>
    >>>Classic way to test NTP functionality is to stop ntpd, set the time by

    >>
    >>This isn't a classic way because it hasn't been an available option for
    >>long enough.

    >
    >
    > The option of stopping ntpd?:-) If you mean -g, I think it has been
    > around since xntpd/v3 days, though possibly with slightly different
    > semantics back then (I'm not sure if it was limited to *one* step).
    > Note, I'm not saying it was *documented*.:-)
    >
    > --Per Hedeland
    > per@hedeland.org



  14. Re: limitation on the client time/date at ntp startup

    In article ,
    "user@domain.invalid" (suspected to be Dave Mills) wrote:

    > I have no idea whatsoever what you are talking about. If you need to


    I have no idea which point you are responding to, as you have used
    a pure top post.

    > test whether the clock state machine correctly responds to large time
    > offsets, then my suggested scheme is exactly what you need. I have


    No. What people actually want to do is to create an acceptance test
    plan that will be understood by someone who doesn't understand what ntpd
    really does, and, quite possibly, to do so when they don't understand
    it themselves.

    This might be a formal acceptance test plan, or it might be an informal
    one in which they demonstrate, to senior management, that ntpd can correct
    time errors.

    Testing the specific step response behaviour in these cases assumes a
    much higher level of technical knowledge than the questions generally
    exhibit.

+ Reply to Thread