"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: >> 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. 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. >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
