[ntp:questions] Re: NTP stepping issue
David L. Mills
mills at udel.edu
Sat Oct 23 23:22:46 UTC 2004
Philip Homburg wrote:
> In article <cldtmo$gde$1 at dewey.udel.edu>,
> David L. Mills <mills at udel.edu> wrote:
>>useful primarily at long poll intervals where errors are dominated by
>>the intrinsic frequency stability (wander) of the clock oscillator. At
>>shorter poll intervals the errors are dominated by phase errors due to
>>network and operating system latencies. The trick is to combine then in
>>an intelligent hybrid loop, as described on the NTP project page.
> The strange thing is that the 500 ppm / 128 ms limit keeps popping up.
> I can understand strange limits closed-source / broken operating systems.
> But somehow that limit is also present on open source operating systems.
I don't understand your comment. Are you saying the 500-PPM limit and/or
128-ms step threshold are strange? On the NTP project page is a briefing
on performance derived from a series of surveys several years ago. The
current limit/thresholds were determined in those surveys based on
probability models. There are a number of things that can go wrong
leading to a stuck conditions at the 500-PPM limit. In all cases I know
the problem has been either a massive error in the clock oscillator
frequency (500 PPM = 43 seconds per day), lost interrupts and
I don't understand your comment about open/closed source operating
systems and whether that affects/is affected by the limit/thresholds. So
far as I know, every operating system, closed or open, has the same
limit/thresholds with the possible exception of Windows. These
limit/thresholds have been the same since NTP Version 2 The 500 PPM
limit is a header define; the thresholds can be tinkered.
>>There is a genuine opportunity to test your theories. See the NTP
>>simulator, which is included in the software distribution. The best
>>place to experiment is in the ntp_loopfilter.c file. The simulator can
>>generate ramps, constant offsets and various combinations of random
>>phase and frequency errors. You can also record real-world data and feed
>>that to the simulator.
> The problem is of course time. The main experiment I want to do is
> black box testing of NTP implementations: create a reference clock with
> a known distortion, feed it to the ntp implementation that is to be tested
> and then poll that implementation to compare the filtered time to
> the input signal.
Yes, the problem is time, your time and mine. That's exactly why the
simluator was built. Testing things in vivo takes lots and lots of time,
especially when testing for stability at long poll intervals. With the
simulator, testing over a week takes a few seconds. You can even turn on
debugging and file statistics, which is really useful in finding little
warts like you will be looking for.
> As far as I know, such a blackbox test setup does not exist.
Again, the black box test setup is the simulator. I make the case it is
a rigorous test, since the black box code really and truly is the same
code as runs in the daemon itself. One thing it does not do at present
is simulate multiple simultaneous associations. Good project for an
ambitions computer science student.
> Maybe one day I can find the time to create such a test environment, but
> I'd rather have somebody else (who also knows enough about statistics to
> do a proper analysis of the raw results) build it.
This has been done several times, in particular by Navy contractors for
the Aegis cruiser and DDX destroyer projects, as well as a number of
other companies and of course our friends in this community.
More information about the questions