Re: Setting the maximum rate of change (HarlanStenn) - NTP

This is a discussion on Re: Setting the maximum rate of change (HarlanStenn) - NTP ; -----Original Message----- From: questions-bounces+gdowd=symmetricom.com@lists.ntp.isc.org [mailto:questions-bounces+gdowd=symmetricom.com@lists.ntp.isc.org] On Behalf Of questions-request@lists.ntp.isc.org Sent: Tuesday, March 20, 2007 5:00 AM To: questions@lists.ntp.isc.org Subject: questions Digest, Vol 29, Issue 56 Send questions mailing list submissions to questions@lists.ntp.isc.org To subscribe or unsubscribe via the World Wide ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Setting the maximum rate of change (HarlanStenn)

  1. Re: Setting the maximum rate of change (HarlanStenn)



    -----Original Message-----
    From: questions-bounces+gdowd=symmetricom.com@lists.ntp.isc.org
    [mailto:questions-bounces+gdowd=symmetricom.com@lists.ntp.isc.org] On
    Behalf Of questions-request@lists.ntp.isc.org
    Sent: Tuesday, March 20, 2007 5:00 AM
    To: questions@lists.ntp.isc.org
    Subject: questions Digest, Vol 29, Issue 56

    Send questions mailing list submissions to
    questions@lists.ntp.isc.org

    To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.ntp.isc.org/mailman/listinfo/questions
    or, via email, send a message with subject or body 'help' to
    questions-request@lists.ntp.isc.org

    You can reach the person managing the list at
    questions-owner@lists.ntp.isc.org

    When replying, please edit your Subject line so it is more specific than
    "Re: Contents of questions digest..."


    Today's Topics:

    1. Re: Setting the maximum rate of change (Harlan Stenn)


    ----------------------------------------------------------------------

    Message: 1
    Date: Tue, 20 Mar 2007 09:57:21 +0000
    From: Harlan Stenn
    Subject: Re: Setting the maximum rate of change
    To: questions@lists.ntp.isc.org
    Message-ID:
    Content-Type: text/plain; charset=ISO-8859-1

    >>> In article <45ffa089$0$9851$426a74cc@news.free.fr>, Spoon

    writes:

    Spoon> Here's why I ask: I'm working with a standard that deals with 27
    Spoon> MHz clocks, and that standard states that the frequency must not
    Spoon> change faster than 75 mHz per second.



    If I understand correctly, the question regards slew rate limits. In an
    environment where you are trying to recover frequency to control some
    playout, there are bandwidth limitations. If you don't constrain slew
    limits, you may exceed the operating envelope of the applications (28ppb
    or here is looks like 2.8ppb? NTSC colorburst?). In the public domain
    implementation, I believe the maximum slew rate is 500ppm. There is no
    other limit unless you play with the tinker command. As the control
    loop is implemented with phase corrections (whether the loop is in fll
    or pll mode), you will need to convert to time domain for constraints.
    You also have to consider error recovery where you are clock hopping and
    you have a presumably good new timebase which has phase discontinuity.

    As you get time from the system clock instead of the ntp clock, you also
    have to deal with phase steps in any case as they are not detectable
    unless you implement another filter based on some local reference.

    I'm not sure that ntp in it's standard compile is well suited for ppb
    range filtering without a considerable length of time (hours) to crank
    out into fll bias (tau) even if you have a stable environ.

    I'm quite interested in Dave's comments regarding the application of the
    ntp protocol, and to some degree the servo, in the ongoing development
    of precise time and frequency transfer applications. While much of the
    Internet will remain best effort, larger segments will be constrained,
    or perhaps deployed with measurement overlays or traffic mitigation
    (mpls or transparent clocks, multi-homed ntp servers as boundary clocks,
    etc). The current bundling of the protocol and algorithms to allow
    hierarchical distribution gets in the way of optimization of ntp in
    these spaces.


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


  2. Re: Setting the maximum rate of change (HarlanStenn)

    In article <4B73D9EBE2327E40B4D69822D7C4580206F75980@sjmail1.s ymmetricom.com>,
    GDowd@symmetricom.com (Greg Dowd) wrote:

    [ Pretty sure the threading is broken after this! ]

    > If I understand correctly, the question regards slew rate limits. In an


    That's not my understanding. My understanding is that he want to
    constrain the first derivative of the frequency correction. That is
    the second derivative of the offset. Slew rate is used to describe
    the frequency correction, particular when it is being used to reduce
    an offset error.

    What's probably implicit is that, in the specification he is trying
    to implement, this is the derivative including the first derivative of
    the crystal frequency, so the 25mHz/27MHz/s (about 0.001 ppm/s) might
    be totally taken up by variations in the crystal frequency. Actually,
    given that he wants this condition met after one minute, but the machine
    probably won't reach thermal equilibrium for more like 15 minutes, I think
    it will almost certainly be violated by the crystal frequency on its own.

    In that case, the only way of achieving conformance is to NOT constrain
    the first derivative of frequency correction, so that there is some
    chance of the frequency being compensated fast enough to compensate for
    the crystal drift.

    [ Further note on threading. This is a newsgroup to which an email
    gateway has been added. If you reply to a digest, on the email side, you
    are likely to generate a thread link to the digest, which never appears
    on the newsgroup, rather than the message to which you are replying. ]

  3. Re: Setting the maximum rate of change

    David Woolley wrote:

    > Greg Dowd wrote:
    >
    >> If I understand correctly, the question regards slew rate limits.

    >
    > That's not my understanding. My understanding is that he want to
    > constrain the first derivative of the frequency correction.


    Correct. I want to know if it's possible to constrain the acceleration.

    > That is
    > the second derivative of the offset. Slew rate is used to describe
    > the frequency correction, particular when it is being used to reduce
    > an offset error.
    >
    > What's probably implicit is that, in the specification he is trying
    > to implement, this is the derivative including the first derivative of
    > the crystal frequency, so the 25mHz/27MHz/s (about 0.001 ppm/s)


    NB: it's 75 mHz/s / 27 MHz i.e. 10 ppm/h

    > might
    > be totally taken up by variations in the crystal frequency. Actually,
    > given that he wants this condition met after one minute, but the machine
    > probably won't reach thermal equilibrium for more like 15 minutes, I think
    > it will almost certainly be violated by the crystal frequency on its own.


    Assume the systems have been running for 24 hours.

    As far as I understand, clock drift rate (what I call acceleration) is a
    function of temperature, voltage, and what else? Assume temperature is
    kept almost constant. I can't say anything about voltage. Since we are
    using ordinary power supplies, it could probably be slightly improved.

    > In that case, the only way of achieving conformance is to NOT constrain
    > the first derivative of frequency correction, so that there is some
    > chance of the frequency being compensated fast enough to compensate for
    > the crystal drift.


    Would the oscillator drift rate be that bad in the situation described
    above?

    Regards.

+ Reply to Thread