trp@CHERRY.CRAY.COM (Todd Pisek) (03/07/91)
I am fairly new to this ntp stuff. We have a need to maintain time to a 1 ms accuracy and to converge to this accuracy within minutes of startup. I have browsed the NTP version 3 specification, especially the local clock sections. I realize there is a qualatative relationship between the convergence rate and the latency involved in obtaining the local time. I also suspect there is a relationship between the consistancy of the latency and accuracy. What I would like to know is if anyone has hard numbers relating the statistical properties of the local clock access path to convergence rate and accuracy. Todd
Mills@udel.edu (03/07/91)
Todd, The time constant of the NTP local clock as presently implemented is about an hour, which in principle completely describes the convergence rate and accuracy. Of course, the time it takes to achieve any particular accuracy depends on how far off you are at startup, which is limited to +-128 ms in the present version. Now, a conforming NTP implementation could simply set the local clock directly upon reboot or when the daemon restarts at the first valid round of NTP messages, which cannot take more than 128 seconds. My implementations don't do that, since I need to restart the daemon for testing and debugging without affecting the local-clock variables. There is also the opportunity to retune the local-clock parameters to widen the bandwidth for special cases, including yours. As you know, the NTP model is an adaptive one, with limit stops at 64 seconds and 1024 seconds. If you are willing to poll at higher rates, say at initialization, then in principle you can adjust the convergence time to any value you wish. For instance, if you poll once per second at startup, the loop time constant is reduced to about a minute. Note that these convergence times refer to time, not to frequency. Convergence in frequency requires about ten times or more the loop time constant. Dave