[ntp:questions] Clock and Network Simulator

David L. Mills mills at udel.edu
Thu Jul 1 20:15:02 UTC 2010


Rob,

With due respect, I don't think you know what you are talking about. The 
original discipline loop described in rfd1305 was refined as described 
in my 1995 paper and further refined over the years since then. For each 
and every refinement a series of tests, both in simulation and in situ, 
were performed with initial offsets up to +-500 PPM and +-100 ms to 
verify correct behavior with the original parameters. The daemon loop is 
required to operate over a time constant between 8 s and 36 h, which is 
an extremely large range as verified by ongoing configurations here.

The kernel loop is designed to replicate the daemon loop over a much 
narrower range between 8s and 1024 s. The ideal poll interval is 16 and 
64 s matching the Allan intercept as described in the literature. It was 
first implemented for the Alpha in 1992 and refined as described in my 
1995 paper and not changed since then. Correct behavior must be 
confirmed by an experiment such as I suggested in a previous message. 
Sound engineering principles project that the behavior at other time 
constants will be as I described. If you don't believe those principles, 
you are not exercising sound engineering judgment.

Dr. Dave

Rob wrote:

>Miroslav Lichvar <mlichvar at redhat.com> wrote:
>  
>
>>On Wed, Jun 30, 2010 at 10:00:06PM +0000, David L. Mills wrote:
>>    
>>
>>>Is there somebody around here that understands feedback control
>>>theory? You are doing extreme violence to determine a really simple
>>>thing, the discipline loop impulse response. There is a much simpler
>>>way.
>>>      
>>>
>>It was a demonstration of what clknetsim can do. You may be able
>>to predict the result, but I'm not. I think being able to verify a
>>theory with simulations is always a good thing.
>>    
>>
>
>Mr Mills is of the school that says "the design predicts that the
>program behaves like that, and the implementation has not changed
>for 10 years, so it must be correct".  While I normally adhere to the
>same principles, it happened just a week or two ago that he had to
>admit that there was a bug in code that he firmly believed was
>correct and that an observed behaviour "could not possibly happen".
>
>So I agree with you that it never hurts to test something that theory
>has already proved to be correct.  Maybe the actually released program
>does not really implement the mechanism that was designed, without
>the programmer knowing it.
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>http://lists.ntp.org/listinfo/questions
>  
>




More information about the questions mailing list