[ntp:questions] Setting the maximum rate of change (Harlan Stenn)

Greg Dowd GDowd at symmetricom.com
Tue Mar 20 13:03:12 UTC 2007


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

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

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

You can reach the person managing the list at
	questions-owner at 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 <stenn at ntp.isc.org>
Subject: Re: [ntp:questions] Setting the maximum rate of change
To: questions at lists.ntp.isc.org
Message-ID: <ywn9648wutj2.fsf at ntp1.isc.org>
Content-Type: text/plain; charset=ISO-8859-1

>>> In article <45ffa089$0$9851$426a74cc at news.free.fr>, Spoon
<devnull at localhost.com> 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.

More information about the questions mailing list