> 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
