-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 5:00 AM
To: [email protected]
Subject: questions Digest, Vol 29, Issue 56
Send questions mailing list submissions to
[email protected]
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
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
Subject: Re: [ntp:questions] Setting the maximum rate of change
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
>>> In article <[EMAIL PROTECTED]>, Spoon
<[EMAIL PROTECTED]> 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.
<snip>
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
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
