Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!uwm.edu!bionet!agate!ucbvax!udel.edu!Mills
From: Mills@udel.edu
Newsgroups: comp.protocols.time.ntp
Subject: Re:  NTP convergence rates
Message-ID: <9103061518.aa03489@huey.udel.edu>
Date: 6 Mar 91 20:18:17 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 28

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