[ntp:questions] NTP phase lock loop inputs and outputs?

skillzero at gmail.com skillzero at gmail.com
Mon May 19 19:00:26 UTC 2008


> 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.

> Why don't you just use the reference implimentation.
> Why do you have to do your own ntp stuff?

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.

> What is your clock? A CD spinning? Those frequencies are nowhere near PPM accuracy.

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.




More information about the questions mailing list