Time until synchronized - NTP

This is a discussion on Time until synchronized - NTP ; >>> In article , anton.a.persson@ericsson.com (Anton Persson A) writes: Anton> We have, however, in the /etc/ntp.conf file explicitly stated that Anton> the daemon should communicate using NTP v3. What this means is that Anton> ntpd says, to to the server ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 48 of 48

Thread: Time until synchronized

  1. Re: poll interval - Clarification! - RFC compliancequestion

    >>> In article <39EA5C210755754BB6F997B693820C2201B44C5E@esealmw12 1.eemea.ericsson.se>, anton.a.persson@ericsson.com (Anton Persson A) writes:

    Anton> We have, however, in the /etc/ntp.conf file explicitly stated that
    Anton> the daemon should communicate using NTP v3. What this means is that
    Anton> ntpd says, to to the server it is synching with, that it uses NTP v3
    Anton> (even though it is capable of v4.) I have no idea how this affects
    Anton> the different state machines running inside the ntpd, just that the
    Anton> packet it sends out on the network state v3 instead of the default
    Anton> v4. The reasons for this is requirements from a legacy project which
    Anton> we are communicating with..

    You should not need to do this.

    When two NTP procecess 'communicate', they each offer the 'highest' version
    they know how to speak and then continue the association at the lower
    version.

    Something like:

    v4: I can talk ntpv4
    v3: I can talk ntpv3
    v4: I'm talking to you at ntpv3

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  2. Re: poll interval - Clarification! -RFCcompliancequestion

    Hi,

    (Steve Kosteckes reply follows further down)

    I am not expecting anything, I first asked if an explicit requirement
    found in RFC 4330 (SNTPv4) is also, implicitly, valid for the RFC
    defining
    the NTPv3 standard (RFC 1305). The requirement in RFC 4330 is as
    follows:

    A client SHOULD increase the poll interval using exponential
    backoff as performance permits and especially if the server does
    not respond within a reasonable time.

    As you should understand, this is not an explicit requirement found in
    RFC 1305,
    but I would like to know if it is an implicit requirement, or if it is
    implemented
    anyway in ntp v4.2.4 (as distributed in Red Hat Enterprise Linux). I.e.
    should
    I expect ntp v4.2.4, as distributed in RHEL, to use this exponential
    backoff
    when I forcefully configure it to use NTPv3 and the connection to the
    NTP server
    is lost? And, if it does indeed implement this even when using V3, how
    long should
    it take for NTP to increase the poll interval from 64 to 128 seconds?

    Some people are asking me why we are forcing it to use NTP v3, the
    reasons for
    this is that our test-environment is also using ntp v4.2.4 from SUSE,
    but the
    target environment is using a NTPv3 implementation (I am not aware of
    exactly
    which implementation this is, but it is not important for a test where
    the
    server has stopped responding). We don't have access to the target
    environment
    in such a way that we can always run tests against it, so therefore we
    force
    ntp 4.2.4 to use v3 explicitly.

    Best regards, Anton Persson

    -----Original Message-----
    From: questions-bounces+anton.a.persson=ericsson.com@lists.ntp.org
    [mailto:questions-bounces+anton.a.persson=ericsson.com@lists.ntp.org] On
    Behalf Of Steve Kostecke
    Sent: den 18 juni 2008 18:03
    To: questions@lists.ntp.org
    Subject: Re: poll interval - Clarification! -
    RFCcompliancequestion

    On 2008-06-17, Anton Persson A wrote:

    > The poll interval is 64 to 1024, seconds. ntpd starts up, locks on
    > target, stays synchronized for a while, then we pull the plug.


    What are you trying to prove by "pulling the plug"?

    > The poll interval is at this time still 64 seconds, how long should it


    > take to step up the interval to 128 seconds for a completely failed
    > link?


    Why would you expect the poll interval to change if ntpd is not
    receiving replies to polls?

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

  3. Re: poll interval - RFC compliance question

    John,

    I don't know if Linux has modified the tree, but there are lots of
    copyrighted files, including many of the refclock drivers and options
    stuff. A list of all known and attributed contributors is on the
    copytright.html page. Some of these go back to 1988.

    Dave

    John Ackermann N8UR wrote:
    > Unruh said the following on 06/15/2008 11:35 AM:
    >
    >
    >>Yes, it is pedantry, since the copyright is automatic and does not need to
    >>be asserted. Ie, that notice is infomational, not a legal requirement.
    >>It simply informs the reader as to who actually owns the copyright. What is
    >>not mere pedantry is where or not this claim is actually true. Many people
    >>have contributed to ntpd, and unless they all transfered copyright to David
    >>Mills, then the claim that he owns the copyright is really false. They all
    >>do (David has copyright interest in all of the works since the other
    >>people's work is derivative of his work, but others have copyright interest
    >>as well.) To keep things perfectly clean, David shoule ask anyone who
    >>contributes to transfer their copyright to him.

    >
    >
    > While the notice is not mandatory, it does have legal value -- in
    > particular, it negates a defense of innocent infringement. And, to
    > claim the international protection of the UCC treaty I referred to in my
    > other message, you do need to include the notice.
    >
    > Your point about whether the copyright notice is accurate is
    > interesting. I wonder if it would even be possible at this point to
    > determine who all the contributors are!
    >
    > I thought that Linux used the CREDITS file as a list of copyright
    > holders, but I just looked at some source and that doesn't appear to be
    > the case -- instead, each source file has its own copyright notice in
    > the name of one or more people, with the COPYING file not listing any
    > copyright owners at all. I guess that has the effect of putting the
    > whole kernel tree under the GPL, but the resulting object file(s) as a
    > collective work of all the contributors.
    >
    > I just looked at the ntp 4.2.0 source (the only tree I have handy at the
    > moment) and the random source files I looked at do not have any
    > copyright notice at all, so the Linux model doesn't appear to be in place.
    >
    > John


  4. Re: poll interval - Clarification! - RFC compliancequestion

    Steve,

    The poll interval backs off if the configured server has not been heard
    for ten intervals, then the interval doubles for each poll until
    reaching 1024 s. This is designed to reduce the network load if nobody
    is home.

    Dave

    Steve Kostecke wrote:

    > On 2008-06-17, Anton Persson A wrote:
    >
    >
    >>The poll interval is 64 to 1024, seconds. ntpd starts up, locks on
    >>target, stays synchronized for a while, then we pull the plug.

    >
    >
    > What are you trying to prove by "pulling the plug"?
    >
    >
    >>The poll interval is at this time still 64 seconds, how long should it
    >>take to step up the interval to 128 seconds for a completely failed
    >>link?

    >
    >
    > Why would you expect the poll interval to change if ntpd is not
    > receiving replies to polls?
    >


  5. Re: poll interval - Clarification! - RFC compliancequestion

    Harlan,

    Not quite. The NTPv4 server replies with the same version as received in
    an NTP packet. The configuration version option applies only to packets
    that are sent unsolicited. Other than this, the version number plays no
    part in packet processing.

    Dave

    Harlan Stenn wrote:

    >>>>In article <39EA5C210755754BB6F997B693820C2201B44C5E@esealmw12 1.eemea.ericsson.se>, anton.a.persson@ericsson.com (Anton Persson A) writes:

    >
    >
    > Anton> We have, however, in the /etc/ntp.conf file explicitly stated that
    > Anton> the daemon should communicate using NTP v3. What this means is that
    > Anton> ntpd says, to to the server it is synching with, that it uses NTP v3
    > Anton> (even though it is capable of v4.) I have no idea how this affects
    > Anton> the different state machines running inside the ntpd, just that the
    > Anton> packet it sends out on the network state v3 instead of the default
    > Anton> v4. The reasons for this is requirements from a legacy project which
    > Anton> we are communicating with..
    >
    > You should not need to do this.
    >
    > When two NTP procecess 'communicate', they each offer the 'highest' version
    > they know how to speak and then continue the association at the lower
    > version.
    >
    > Something like:
    >
    > v4: I can talk ntpv4
    > v3: I can talk ntpv3
    > v4: I'm talking to you at ntpv3
    >


  6. Re: poll interval - Clarification! - RFCcompliancequestion

    Anton Persson A wrote:

    >
    > A client SHOULD increase the poll interval using exponential
    > backoff as performance permits and especially if the server does
    > not respond within a reasonable time.
    >
    > As you should understand, this is not an explicit requirement found in
    > RFC 1305,


    In the case of servers that are replying, the NTP specification provides
    a lot of detail about exactly what "as performance permits" means, and
    does require an exponential backoff whilst the quality of the server is
    such that it is of benefit.

  7. Re: poll interval - Clarification! - RFC compliancequestion

    Steve Kostecke writes:

    >On 2008-06-17, Anton Persson A wrote:


    >> The poll interval is 64 to 1024, seconds. ntpd starts up, locks on
    >> target, stays synchronized for a while, then we pull the plug.


    >What are you trying to prove by "pulling the plug"?


    >> The poll interval is at this time still 64 seconds, how long should it
    >> take to step up the interval to 128 seconds for a completely failed
    >> link?


    >Why would you expect the poll interval to change if ntpd is not
    >receiving replies to polls?


    NTP v4states that you should increase the polll interval if no replies are
    received. The problem was that some decreased the poll interval, swamping
    the net.



  8. Re: poll interval - RFC compliance question

    David Woolley wrote:
    > Anton Persson A wrote:
    >
    >> we are using the ntp v3 protocol, as defined in RFC1305, however
    >> I have a question running through my head when I consider the poll
    >> interval.

    >
    > You are going to have limited success getting help on that specification
    > here as it is considered obsolete, even though the version 4
    > specification is still only, officially, a draft. As such people are
    > going to give you the answers for version 4 or have to cast their minds
    > back several years.


    I don't think that RFC 1305 specified a backoff requirement. In the
    current NTP v4 draft, we require a backoff if you receive a KOD with a
    RATE kiss code but it does not specify a specific amount.

    Danny

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3