On 2015-02-12, Rob <[email protected]> wrote: > Brian Inglis <[email protected]> wrote: >> On 2015-02-12 03:00, Rob wrote: >>> [email protected] <[email protected]> wrote: >>>> Yes,I just tested it and found that the synchronization of NTP is really >>>> slow. >>> >>> That is because ntpd is not designed to correct arbitrary errors that >>> you have applied externally. It is designed to lock to the correct time >>> and stay locked to that (within a few milliseconds when you use the network, >>> or within a few microseconds when you have a local reference). >>> >>> The typical "acceptance test" scenario of "let's set the clock one hour >>> wrong while the system is running and see that ntpd corrects it" just is >>> not going to work. Drop that test, it should not be on the test list >>> for ntpd. When you need that test, use another product. >> >> The test should be: >> set the clock one hour wrong; >> start ntpd -g; >> measure how long it takes to get within 128ms, 64ms, 32ms, 16ms, ... of UTC; > > Yes, that would work. But that was obviously not how it was tested and > I have seen this kind of posting here many times. It is apparently a > common (wrong) way of testing.
She never said how she tested it, so making assumptions and then blaming her on the basis of those assumptions is hardly fair. A scenario where one could be out by a second is the leap second. Suddenly the remote clock reports that your local time is out by a second. Your local clock begins to slew to correct that, but after many seconds your local ntpd decides to step, but its slew rate is now wrong, and it must correct that. How long does it take to settle down again? That is not only a valid test, but one that many many instances of ntpd run into, because for example, their source does not properly report leap seconds. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
