[ntp:questions] Re: NTP stepping issue

[David L. Mills]

Philip,

See inline.

Dave

Philip Homburg wrote:
> In article <cldtmo$gde$1 at dewey.udel.edu>,
> David L. Mills <mills at udel.edu> wrote:
> 
>>It is 
>>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 
misconfigured kernels.

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.