# NTP phase lock loop inputs and outputs?

Show 40 post(s) from this thread on one page
Page 1 of 2 1 2 Last
• 05-19-2008, 04:10 AM
unix
NTP phase lock loop inputs and outputs?
I'm doing NTP exchanges to determine my clock offset. I use this to
adjust my clock frequency, but there's a lot of lag so I overshoot by
too much and it oscillates around the reference frequency. This is an
audio clock so I have to do my own NTP stuff. I think I want to use a
phase lock loop as described in the NTP literature, but I'm confused
by the terminology (and possibly the math) so I'm not sure what the
inputs or outputs should be.

If my reference clock is running at ~44100 Hz and through my NTP
exchanges, I get an instantaneous offset of -20 Hz, I want to adjust
my clock to 44080 Hz, but no more than 5 Hz/sec (so it's not audible)
and that instantaneous offset will likely change as it narrows in on
the true frequency. The formula I've seen for NTP's PLL is:

y = (Vs*u) / (64Tc)^2

I do NTP packet exchanges every 2 seconds so I think that resolves to:

y = (2*Vs) / 16384

Is Vs the actual reference frequency estimate (44080 Hz in this case)?
I'm not sure how I use the result of the equation to adjust the clock.

I guess my question is that if I think my frequency is 44100 Hz and
via an NTP exchange, I calculate I'm off by -20 Hz, how should I
calculate what I should set my frequency to, to slowly sync to the
reference frequency (no more than 5 Hz/sec) while also factoring in
the previous clock offset estimate?

The current scheme I'm using to simply set my clock to 44100-5 Hz
(capping the -20 Hz offset to 5) every 2 seconds doesn't work very
well because it's too slow to realize that the direction of the offset
has changed because the absolute clock offset is still negative (e.g.
went from -20 to -5, but it's still negative so it thinks it still
needs to reduce the clock frequency when it should probably increase
it or leave it the same).
• 05-19-2008, 06:46 AM
unix
Re: NTP phase lock loop inputs and outputs?
[email]skillzero@gmail.com[/email] wrote:
[color=blue]
> If my reference clock is running at ~44100 Hz and through my NTP
> exchanges, I get an instantaneous offset of -20 Hz,[/color]

.....you have broken hardware. Once you correct for systematic error, a
crystal should be within single figure parts per million, even over a
wide temperature range, so your maximum frequency error in the sampling

Note that the maximum correction that ntpd can apply is 500ppm, which
corresponds to 25Hz at 44.1kHz. It will only apply that correction if
there is a sustained and serious synchronisation error.

Incidentally, this is an example of an application where running the
core clock discipline algorithm at long intervales would be very disruptive.
• 05-19-2008, 07:22 AM
unix
Re: NTP phase lock loop inputs and outputs?
On May 18, 11:46*pm, David Woolley[color=blue][color=green]
> > If my reference clock is running at ~44100 Hz and through my NTP
> > exchanges, I get an instantaneous offset of -20 Hz,[/color]
>
> ....you have broken hardware. *Once you correct for systematic error, a
> crystal should be within single figure parts per million, even over a
> wide temperature range, so your maximum frequency error in the sampling

I was just giving an example for illustrative purposes, but this
hardware can be up to 50 Hz off in normal conditions.
[color=blue]
> Note that the maximum correction that ntpd can apply is 500ppm, which
> corresponds to 25Hz at 44.1kHz. *It will only apply that correction if
> there is a sustained and serious synchronisation error.[/color]

I'm not using ntpd. This is a specialized application that uses the
NTP protocol and I'm trying to adapt some of the NTP algorithms to
discipline an audio clock.

I'm mainly interested in understanding the NTP phase lock loop, what
its inputs should be given my data, how to apply it to that data, and
how to convert the results into something I can use to adjust the
hardware frequency.

The NTP literature I've read is very heavy on terminology I'm not
familiar with so I was hoping for something along the lines of "if an
NTP exchange says your clock is -20Hz off (and that's the only data I
really have), plug that number into this equation, and the result is
the number of Hz to add or subtract from your current frequency to
slew it toward the reference frequency (until the next NTP exchange in
2 seconds)".

The simple scheme I'm using now overshoots then undershoots too much
so I was hoping something like the NTP phase lock loop could help
improve it.
• 05-19-2008, 08:05 AM
unix
Re: NTP phase lock loop inputs and outputs?
[email]skillzero@gmail.com[/email] wrote:
[color=blue]
> I was just giving an example for illustrative purposes, but this
> hardware can be up to 50 Hz off in normal conditions.[/color]

You shouldn't use your phase locked loop to correct this sort of
1,000ppm error. You should calibrate it out before you start.

Note that, if you only let ntpd use its PLL algorithms, its response to
this sort of error is very poor. With ntpd you would really need to
ensure it does a frequency calibration, in which it waits about 15
minutes without correcting frequency and looks at the total drift, then
instantaneously applies a total correction for that drift.

Phase lock loops are good at tracking slow variations in remote
frequency/compensating for slow variations in local frequency, but they
are not good at getting initial lock, unless you sample very fast. (A
pure hardware PLL would sample at 44.1kHz, in this case, but you
presumably have network jitter and packetisation effects that compromise

Even with fast true phase locking at the signal frequency, PLLs that
have to change frequency generally have a fast acquisition mode, before
they enter the tracking mode.
• 05-19-2008, 03:02 PM
unix
Re: NTP phase lock loop inputs and outputs?
"skillzero@gmail.com" <skillzero@gmail.com> writes:
[color=blue]
>I'm doing NTP exchanges to determine my clock offset. I use this to
>adjust my clock frequency, but there's a lot of lag so I overshoot by[/color]

What do you mean "a lot of lag"?
[color=blue]
>too much and it oscillates around the reference frequency. This is an[/color]

The time constants of the reference ntp are essentially a second order
critically damped system. Yours seems to be underdamped.

Why don't you just use the reference implimentation.
[color=blue]
>audio clock so I have to do my own NTP stuff. I think I want to use a[/color]

Why do you have to do your own ntp stuff?
[color=blue]
>phase lock loop as described in the NTP literature, but I'm confused
>by the terminology (and possibly the math) so I'm not sure what the
>inputs or outputs should be.[/color]
[color=blue]
>If my reference clock is running at ~44100 Hz and through my NTP[/color]

I have no idea what you are describing here. What is your clock? A CD
spinning? Those frequencies are nowhere near PPM accuracy.
[color=blue]
>exchanges, I get an instantaneous offset of -20 Hz, I want to adjust[/color]

What in the world does this mean?
[color=blue]
>my clock to 44080 Hz, but no more than 5 Hz/sec (so it's not audible)
>and that instantaneous offset will likely change as it narrows in on
>the true frequency. The formula I've seen for NTP's PLL is:[/color]
[color=blue]
> y = (Vs*u) / (64Tc)^2[/color]
[color=blue]
>I do NTP packet exchanges every 2 seconds so I think that resolves to:[/color]
[color=blue]
> y = (2*Vs) / 16384[/color]
[color=blue]
>Is Vs the actual reference frequency estimate (44080 Hz in this case)?
>I'm not sure how I use the result of the equation to adjust the clock.[/color]
[color=blue]
>I guess my question is that if I think my frequency is 44100 Hz and
>via an NTP exchange, I calculate I'm off by -20 Hz, how should I
>calculate what I should set my frequency to, to slowly sync to the
>reference frequency (no more than 5 Hz/sec) while also factoring in
>the previous clock offset estimate?[/color]
[color=blue]
>The current scheme I'm using to simply set my clock to 44100-5 Hz
>(capping the -20 Hz offset to 5) every 2 seconds doesn't work very
>well because it's too slow to realize that the direction of the offset
>has changed because the absolute clock offset is still negative (e.g.
>went from -20 to -5, but it's still negative so it thinks it still
>needs to reduce the clock frequency when it should probably increase
>it or leave it the same).[/color]

I think maybe you need to be clearer in what it is that you are trying to
do.
ntp does not exchange frequencies. ntp exchanges time stamps. How do you
generate your time stamps? What is that "reference frequency"?

• 05-19-2008, 03:35 PM
unix
Re: NTP phase lock loop inputs and outputs?
Unruh wrote:
[color=blue]
> I think maybe you need to be clearer in what it is that you are trying to
> do.
> ntp does not exchange frequencies. ntp exchanges time stamps. How do you
> generate your time stamps? What is that "reference frequency"?
>[/color]
The frequency says it all.
The OP wants to have multiple hosts synced for audio sampling.

uwe

• 05-19-2008, 05:57 PM
unix
Re: NTP phase lock loop inputs and outputs?
"skillzero@gmail.com" <skillzero@gmail.com> writes:[color=blue]
>I'm doing NTP exchanges to determine my clock offset. I use this to
>adjust my clock frequency, but there's a lot of lag so I overshoot by
>too much and it oscillates around the reference frequency. This is an
>audio clock so I have to do my own NTP stuff. ...[/color]

Are you interested in time as well as frequency, or just frequency?

--
These are my opinions, not necessarily my employer's. I hate spam.

• 05-19-2008, 07:00 PM
unix
Re: NTP phase lock loop inputs and outputs?
> What do you mean "a lot of lag"?

Just that changes I make to correct for frequency offset take a while
to fully take effect. If I detect that my current frequency is off by
5 Hz, I reduce my frequency by 5 Hz, but in 2 seconds when I do my
next NTP packet exchange, I see that I'm now off by say 4 Hz. If I
were to stop here, I might find that my current frequency is perfect,
but because it's still off by 4 Hz at this moment, I'll try to reduce
by another 4 Hz and so on. When it gets to 0 Hz, I'll stop correcting,
but by then I've adjusted way too far and it's off in the other
direction so I'll start increasing my frequency. I end up seeing
something like this in terms of clock offsets: -5, -4, -2, 0, +2 +4,
+5, +4, +1, 0, -2, -4, etc.

I think my problem is that I'm always looking at the absolute
frequency offset and making a correction based on that without
considering the trend of the offset. From the previous example, at the
second sample, the absolute offset is still -4, but since it was -5
before that, it is trending toward 0 now, but my algorithm doesn't
recognize that.

It seems like the NTP PLL is designed to solve this kind of problem.
I'm having trouble figuring how how to convert the data I have into
something I can plug into it.
[color=blue]
> Why don't you just use the reference implimentation.
> Why do you have to do your own ntp stuff?[/color]

The NTP reference implementation is a huge amount of code that
wouldn't even fit in the very small systems I'm working with. I'm also
trying to sync an audio frequency rather than the time-of-day that NTP
normally deals with. I'm not looking to just drop in some code. I want
to understand it.
[color=blue]
> What is your clock? A CD spinning? Those frequencies are nowhere near PPM accuracy.[/color]

The clocks driving the frequency have reasonable precision (50 PPM or
so), but the accuracy may be initially off by up to 1000 PPM. I think
ntpd would just step the clock initially then start using its PLL, but
I can't step my "clock", I can only adjust the frequency that drives
it (I wouldn't want to step it anyway because you'd be able to hear
that).

Rather than stepping when the offset is initially large, I want to
aggressively adjust (up to 500 PPM) the frequency when the offset is
large, but then factor in previous changes and their results so it
realizes that even if the absolute frequency offset *at this moment*
is off, it is trending toward sync and it should slow down or stop its
adjustments so it doesn't overshoot the mark.
• 05-19-2008, 07:25 PM
unix
Re: NTP phase lock loop inputs and outputs?
A simple algorithm I have used in the pastis

to measure phase offset.

in short intervals starting with an interval in
which under worst case errors phase changes
of less than 180 deg can happen.

correct the frequency error for that.
lengthen the interval, rinse and repeat.
until your phase offset is constant.

measure phase error from there.

then compute a frequency offset you need
to apply to have the phase change over this
error in a given timeframe
or
compute a time you have to shift frequency by
a given amount.

after the time has elapsed switch back to your
previously measured offset.

You should now have about zero frequency and phase error.
you will now have to fix the small errors in f and p
continuously.

I have used this ages ago (~1989) for a positioning system
that had to lock on the Stereo Pilot Tone or the RDS carrier of
multiple FM Broadcast transmitter ( that ran in lockstep).

uwe
• 05-19-2008, 07:28 PM
unix
Re: NTP phase lock loop inputs and outputs?
> Are you interested in time as well as frequency, or just frequency?

Just frequency. This frequency controls a counter. I use a more
traditional NTP-sync'd time (which is accurate to a few PPM) to map
that counter value to an absolute time (e.g at counter X, the NTP time
is Y). Then I do NTP packet exchanges using that mapped time to
estimate my frequency offset. I then increase/reduce the counter
frequency to try to sync with the frequency on the other side.

That frequency adjustment is what I'd like to improve to minimize
overshooting the true frequency.
• 05-19-2008, 08:15 PM
unix
Re: NTP phase lock loop inputs and outputs?
Uwe Klein <uwe_klein_habertwedt@t-online.de> writes:
[color=blue]
>Unruh wrote:[/color]
[color=blue][color=green]
>> I think maybe you need to be clearer in what it is that you are trying to
>> do.
>> ntp does not exchange frequencies. ntp exchanges time stamps. How do you
>> generate your time stamps? What is that "reference frequency"?
>>[/color]
>The frequency says it all.
>The OP wants to have multiple hosts synced for audio sampling.[/color]

I thought that sound was driven by a crystal on the soundcard, not by the
cpu timer.
And again, ntp exchanges time stamps, not frequencies.

[color=blue]
>uwe[/color]

• 05-19-2008, 08:29 PM
unix
Re: NTP phase lock loop inputs and outputs?
Unruh wrote:[color=blue]
> Uwe Klein <uwe_klein_habertwedt@t-online.de> writes:
>
>[color=green]
>>Unruh wrote:[/color]
>
>[color=green][color=darkred]
>>>I think maybe you need to be clearer in what it is that you are trying to
>>>do.
>>>ntp does not exchange frequencies. ntp exchanges time stamps. How do you
>>>generate your time stamps? What is that "reference frequency"?
>>>[/color]
>>
>>The frequency says it all.
>>The OP wants to have multiple hosts synced for audio sampling.[/color]
>
>
> I thought that sound was driven by a crystal on the soundcard, not by the
> cpu timer.
> And again, ntp exchanges time stamps, not frequencies.[/color]
change horses?

uwe
• 05-19-2008, 09:30 PM
unix
Re: NTP phase lock loop inputs and outputs?
"skillzero@gmail.com" <skillzero@gmail.com> writes:
[color=blue][color=green]
>> What do you mean "a lot of lag"?[/color][/color]
[color=blue]
>Just that changes I make to correct for frequency offset take a while
>to fully take effect. If I detect that my current frequency is off by
>5 Hz, I reduce my frequency by 5 Hz, but in 2 seconds when I do my
>next NTP packet exchange, I see that I'm now off by say 4 Hz. If I
>were to stop here, I might find that my current frequency is perfect,
>but because it's still off by 4 Hz at this moment, I'll try to reduce
>by another 4 Hz and so on. When it gets to 0 Hz, I'll stop correcting,
>but by then I've adjusted way too far and it's off in the other
>direction so I'll start increasing my frequency. I end up seeing
>something like this in terms of clock offsets: -5, -4, -2, 0, +2 +4,
>+5, +4, +1, 0, -2, -4, etc.[/color]
[color=blue]
>I think my problem is that I'm always looking at the absolute
>frequency offset and making a correction based on that without
>considering the trend of the offset. From the previous example, at the
>second sample, the absolute offset is still -4, but since it was -5
>before that, it is trending toward 0 now, but my algorithm doesn't
>recognize that.[/color]

Again, I am afraid this is making no sense. How do you compare your
frequencies? What do you do when you have made the comparison? What do you
change to change teh frequency.

[color=blue]
>It seems like the NTP PLL is designed to solve this kind of problem.
>I'm having trouble figuring how how to convert the data I have into
>something I can plug into it.[/color]
[color=blue][color=green]
>> Why don't you just use the reference implimentation.
>> Why do you have to do your own ntp stuff?[/color][/color]
[color=blue]
>The NTP reference implementation is a huge amount of code that
>wouldn't even fit in the very small systems I'm working with. I'm also
>trying to sync an audio frequency rather than the time-of-day that NTP
>normally deals with. I'm not looking to just drop in some code. I want
>to understand it.[/color]
[color=blue][color=green]
>> What is your clock? A CD spinning? Those frequencies are nowhere near PPM accuracy.[/color][/color]
[color=blue]
>The clocks driving the frequency have reasonable precision (50 PPM or
>so), but the accuracy may be initially off by up to 1000 PPM. I think
>ntpd would just step the clock initially then start using its PLL, but
>I can't step my "clock", I can only adjust the frequency that drives
>it (I wouldn't want to step it anyway because you'd be able to hear
>that).[/color]
[color=blue]
>Rather than stepping when the offset is initially large, I want to
>aggressively adjust (up to 500 PPM) the frequency when the offset is
>large, but then factor in previous changes and their results so it
>realizes that even if the absolute frequency offset *at this moment*
>is off, it is trending toward sync and it should slow down or stop its
>adjustments so it doesn't overshoot the mark.[/color]
• 05-19-2008, 10:00 PM
unix
Re: NTP phase lock loop inputs and outputs?
> Again, I am afraid this is making no sense. How do you compare your[color=blue]
> frequencies? What do you do when you have made the comparison? What do you
> change to change teh frequency.[/color]

When I do an NTP exchange of timestamps, I take the resulting
timestamp offset and convert it to the timescale of my audio clock
(i.e. if at audio time X, NTP time is Y then at NTP time A, I can
calculate audio time is B). I compare my audio time with the peer's
audio time to come up with an audio clock offset. So if via NTP
exchanges, I calculate an audio clock offset of 5 units, that maps to
the frequency being off by 5 Hz. So if my clock is set to 44100 Hz and
it's off by +5, I change my clock to 44105 Hz. I change the frequency
by setting a hardware register to the value 44105 (in this case).

The problem is that this change won't be reflected immediately. Even
if I 44105 Hz is exactly in sync with the peer, when I do another NTP
exchange in 2 seconds, it won't have enough time to compensate for the
existing offset so I may still calculate an offset of say 4 Hz then 3
Hz in another 2 seconds, etc. By the time I get to 0, I may have set
my frequency to 44115 Hz and now it's too fast so it'll start getting
negative offsets. And it cycles back and forth like that because I'm
not taking into consideration the relative change.

Figuring out a good way to incorporate the relative change to
discipline the clocks is what I'm hoping the NTP algorithms can do.
• 05-19-2008, 10:14 PM
unix
Re: NTP phase lock loop inputs and outputs?
[email]skillzero@gmail.com[/email] wrote:
[color=blue]
>
> The problem is that this change won't be reflected immediately. Even
> if I 44105 Hz is exactly in sync with the peer, when I do another NTP
> exchange in 2 seconds, it won't have enough time to compensate for the
> existing offset so I may still calculate an offset of say 4 Hz then 3
> Hz in another 2 seconds, etc. By the time I get to 0, I may have set
> my frequency to 44115 Hz and now it's too fast so it'll start getting
> negative offsets. And it cycles back and forth like that because I'm
> not taking into consideration the relative change.[/color]

You have to damp the loop, the same as you have to damp the suspension
in a car. The general form of a commodity industrial controller
involves adding proportional, differential and integral terms, hence
they are called PIDs.

You stop the overshoot by adding a term based on rate at which you are
changing the value. There is particular level of correction that
produces the fastest convergence without any over shoot. Although I
forget it, the actual formula is high school level mechanics.

You don't need an integral term, because you are not trying to zero the
phase error.
• 05-19-2008, 10:37 PM
unix
Re: NTP phase lock loop inputs and outputs?
> You have to damp the loop, the same as you have to damp the suspension[color=blue]
> in a car. *The general form of a commodity industrial controller
> involves adding proportional, differential and integral terms, hence
> they are called PIDs.
>
> You stop the overshoot by adding a term based on rate at which you are
> changing the value. *There is particular level of correction that
> produces the fastest convergence without any over shoot. *Although I
> forget it, the actual formula is high school level mechanics.
>
> You don't need an integral term, because you are not trying to zero the
> phase error.[/color]

I've thought about my own schemes for doing this kind of thing, but I
was hoping to benefit from the experience of NTP to find a proven
scheme rather than just something I hack up. Everything I read is so
heavy on the jargon of control theory and electrical circuits that
it's difficult for me to have confidence in the way I turn it into
code. My ad hoc schemes sorta work, but I want a more solid
understanding of feedback systems rather than the more statistical
approach I've been taking.

I'll check out PIDs. Thanks.
• 05-19-2008, 11:59 PM
unix
Re: NTP phase lock loop inputs and outputs?
"skillzero@gmail.com" <skillzero@gmail.com> writes:
[color=blue][color=green]
>> Again, I am afraid this is making no sense. How do you compare your
>> frequencies? What do you do when you have made the comparison? What do you
>> change to change teh frequency.[/color][/color]
[color=blue]
>When I do an NTP exchange of timestamps, I take the resulting
>timestamp offset and convert it to the timescale of my audio clock
>(i.e. if at audio time X, NTP time is Y then at NTP time A, I can
>calculate audio time is B). I compare my audio time with the peer's
>audio time to come up with an audio clock offset. So if via NTP
>exchanges, I calculate an audio clock offset of 5 units, that maps to
>the frequency being off by 5 Hz. So if my clock is set to 44100 Hz and
>it's off by +5, I change my clock to 44105 Hz. I change the frequency
>by setting a hardware register to the value 44105 (in this case).[/color]

I do not understand this. You seem to be measuring the offsets, not the
frequencies. The offset is irrelevant. What you want to do is to measure
the offset twice, and ask if the difference is constant or not. Ie, th
eoffset does not correspond to being off by 5Hz.

[color=blue]
>The problem is that this change won't be reflected immediately. Even[/color]

Sure it is.
[color=blue]
>if I 44105 Hz is exactly in sync with the peer, when I do another NTP
>exchange in 2 seconds, it won't have enough time to compensate for the
>existing offset so I may still calculate an offset of say 4 Hz then 3[/color]

But you do not care about the offset. You just want the frequencies to be
equal.

[color=blue]
>Hz in another 2 seconds, etc. By the time I get to 0, I may have set
>my frequency to 44115 Hz and now it's too fast so it'll start getting
>negative offsets. And it cycles back and forth like that because I'm
>not taking into consideration the relative change.[/color]

So, take in account relative change.

[color=blue]
>Figuring out a good way to incorporate the relative change to
>discipline the clocks is what I'm hoping the NTP algorithms can do.[/color]

ntp is designed to get rid of both the offset and the frequency
differences. You just want to get rid of freq differences.

• 05-20-2008, 06:35 AM
unix
Re: NTP phase lock loop inputs and outputs?
Unruh wrote:
[color=blue]
> I do not understand this. You seem to be measuring the offsets, not the
> frequencies. The offset is irrelevant. What you want to do is to measure[/color]

Measuring phase error to control frequency is pretty much THE standard
way of doing it in modern electronics. It's called a phase locked loop
(PLL) and it is getting difficult to find any piece of electrnics that
doesn't include one these days. E.g. the typical digitally tuned radio
or TV has a crystal oscillator, which is divided down to the channel
spacing or a sub-multiple, and a configurable divider on the local
oscillator divides that down to the same frequency. The resulting two
signals are then phase locked, by measuring the phase error on each
cycle, low pass filtering it, and using it to control the local
oscillator frequency, resulting in their matching in frequency, and
having some constant phase error.
[color=blue]
> the offset twice, and ask if the difference is constant or not. Ie, th
> eoffset does not correspond to being off by 5Hz.[/color]

ntpd only uses this method on a cold start, to get the initial coarse
calibration. Typical electronic implementations don't use it at all,
but either do a frequency sweep or simply open up the low pass filter,
to get initial lock.
• 05-20-2008, 08:59 AM
unix
Re: NTP phase lock loop inputs and outputs?
> The general form of a commodity industrial controller[color=blue]
> involves adding proportional, differential and integral terms, hence
> they are called PIDs.[/color]

I implemented a PID in software and after a little experimenting with
the gain parameters, I'm able to get and maintain sync. There is a
little oscillation, but it's within about 20 PPM, which is within the
noise of my system. Thanks for pointing me the right direction.
• 05-20-2008, 04:29 PM
unix
Re: NTP phase lock loop inputs and outputs?
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
[color=blue]
>Unruh wrote:[/color]
[color=blue][color=green]
>> I do not understand this. You seem to be measuring the offsets, not the
>> frequencies. The offset is irrelevant. What you want to do is to measure[/color][/color]
[color=blue]
>Measuring phase error to control frequency is pretty much THE standard
>way of doing it in modern electronics. It's called a phase locked loop[/color]

Sure. In the case of ntp you want to have zero phase error. ntp reduces the
phase error slowly by changing the frequency. This has the advantage that
the frequency error also gets reduced (slowly). He wants to reduce the
frequency error only. He does not give a damn about the phase error
apparently. Thus you do NOT want to reduce the frequecy error by attacking
the phase error. That is a slow way of doing it. You want to estimate the
frequency error directly. Now in his case he is doing so by measuring the
phase, so you need at least two phase measurements to estimate the
frequency error. But you do NOT want to reduce the frequency error by
reducing the phase error-- far too slow.

One way of reducing the frequency error is to use the ntp procedure but
applied to the frequency. But you must feed in an estimate of the frequecy
error. Anothr way is the chrony technique. -- collect phase points, do a
least squares fit to find the frequency, and then use that information to
drive the frequecy to zero. To reuse past data, also correct the prior
phase measurements by the change in frequency.
(t_{i-j}-=(t_{i}-t_{i-j}) df
[color=blue]
>(PLL) and it is getting difficult to find any piece of electrnics that
>doesn't include one these days. E.g. the typical digitally tuned radio[/color]

A PLL is a dirt simply thing to impliment electronically. A few resistors
and capacitors. It however is a very simply Markovian process. There is far
more information in the data than that, and digititally it is easy to
impliment far more complex feedback loops than that.

[color=blue]
>or TV has a crystal oscillator, which is divided down to the channel
>spacing or a sub-multiple, and a configurable divider on the local
>oscillator divides that down to the same frequency. The resulting two
>signals are then phase locked, by measuring the phase error on each
>cycle, low pass filtering it, and using it to control the local
>oscillator frequency, resulting in their matching in frequency, and
>having some constant phase error.[/color]
[color=blue][color=green]
>> the offset twice, and ask if the difference is constant or not. Ie, th
>> eoffset does not correspond to being off by 5Hz.[/color][/color]
[color=blue]
>ntpd only uses this method on a cold start, to get the initial coarse
>calibration. Typical electronic implementations don't use it at all,
>but either do a frequency sweep or simply open up the low pass filter,
>to get initial lock.[/color]

And? You are claiming that that is efficient or easy? I would claim the
latter. And his requirements are NOT ntp's requirements. He does not care