On 2015-02-12, catherine.wei1...@gmail.com <catherine.wei1...@gmail.com> wrote: > On Wednesday, February 11, 2015 at 12:55:02 AM UTC+8, Jochen Bern wrote: >> On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote: >> > However, when I wait for several minutes, the time can be adjusted to >> > the right time. I couldn't see the gradual changes of offset. Is that >> > normal? >> >> Assuming that you're using a minimalistic configuration: Yes. >> >> ntpd would take almost three months to *gradually* eliminate (slew) one >> hour of offset, so as soon as the >> offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it >> gave up all hope for the universe and "just set the clock" hard (step). >> >> Regards, >> J. Bern >> -- >> *NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>: >> Server--Storage--Virtualisierung--Management SW--Passion for Performance >> Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/> >> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt >> PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 >> Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 >> Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel > > > > Yes,I just tested it and found that the synchronization of NTP is really slow.
There are two parts to this. The first is the large offset problem, where delta t is many seconds. Here the 500PPM problem sets in and it would take forever to fix that offset, so ntpd simply steps the clock if the offset is greater than 128us, and quits if greater than 1000 sec (unless you use the -g in which case it fixes that large an offset once). The other is if you have an offset of say 50ms, The ntpd takes a long time because of design decisions. a) ntpd throws away about 7 out of 8 polls in order to "fix" the problem of wildly varying round trip times even if there are no such wildly varying offset times. That makes the effective poll interval 8 times longer than the actual poll interval. And then ntpd only slowly changes to the drift rate to fix that offset in order to keep the running of ntpd stable. The simply feedback loop used by ntpd could go unstable if it changed the drift rate too quickly, because the decision was to use an very simply feedback mechanism to run ntpd. (Probably on the KISS principle, and because it is easily analysed to determine stability). This means that if you are using say a PPS source, which gives microsecond long term offset, it can take many hours to get there, even if you or I looking at the offsets could see that it is off by ms after the first few poll intervals. The decision to have stability and simplicity over speed was made a long time ago by Mills. It was not a bad decision, especially in the early days when round trip times did fluctuate wildly sometimes, and where ms resolution was doing well. Now that usec and nsec resolution is possible, the design decisions are a bit more problematic. > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions