[ntp:hackers] Does ntpd need to whine more ?

David L. Mills mills at udel.edu
Tue Oct 4 02:44:30 UTC 2005


P-H,

Discussion on poles and zeros for the PLL and FLL are in my May 1992 
technical report "Modelling and Analysis of Computer Network Clocks." 
While that analysis could be used as the basis of a specification, since 
after all the fixed parameters were defined, I don't think the WG would 
accept a standard expressed in that way. Not many in the client 
population have background in feedback control systems, Bode plots or 
Laplace transforms.

However, the poll-adjust algorithm is more intricate; a precurser is in 
my 1998 SIGCOMM paper, but simplified and improved since then. It is 
vital that the loop dynamics, including the time constant and PLL/FLL 
weights be standardized, at least on the midstream servers. I have lots 
of practical experience on what happens if not.

I'm sorry you don't trust the simulator. It does include the entire 
suite of software modules of the in-vivo article, with the only 
difference the synthentic moise generators and scripts used to simulate 
body blows. There is no way I could have refined the poll-adjust 
algorithm with poll intervals to 36 hours without it.

I do not plead guilty for ignoring data documenting some sort of 
misbehavior or other; in fact, I have drowned in it. All cases to date 
have been the result of a bug on my part due to some extreme scenario I 
didn't expect or predict. Some I found in simulation, others by painful 
reconstruction of the scenario and rigorous testing. The beast is an 
incredibly complicated interacting real-time program and I wouldn't be 
surprised if more bugs were found.

I don't think it was you that started me on the nanokernel trail. The 
PTTI paper was in 2000, but my records with OSF-1 go back to 1995. The 
challenge was to refine the method to work with a SMP Alpha; the 
nanoseconds were an afterthought when I realized the PCC residuals due 
to oscillator wander required that precision.

I won't coment on your judgement about lack of progress. Depends on 
where you look. Autoconfiguration and public key authentication caught 
my eye. I thought it necessary to construct the code skeleton, flow 
charts and test plans in order to support the specification project. I'm 
not saying this stuff is progress at all, just that it and the book 
consumed a lot of work that might otherwise been spent on algorithmic 
refinement.

Yes, the WG is a bunch of rubberstampers. That's what a specification 
task force does. There are or course interesting issues that develop 
from the dialog that might suggest future research agenda. YOur voice 
would be a useful contribution to the activity.

Dave

Poul-Henning Kamp wrote:

> In message <43415079.6040803 at udel.edu>, "David L. Mills" writes:
>
>> Your tone is dissapointing, but I am not going to argue with you.
>> Please, and I am serious about this, take your reservations to the NTP
>> WG and be heard.
>
>
> Dave,
>
> If my tone is dissapointing (and/or dissappointed), then it is
> because I have tried at various intervals over the last decade to
> convince you that NTPD could do better and been told "it works great
> in my simulator" with no appearant willingness to listen to dissenting
> points of view, even when actual data is produced.
>
> I'm proud that I managed to persuade you to take the step from micro
> to nanoseconds but that seems to be as far as I could shift you.
>
> This lack of progress is also to a large degree why I have pulled
> out of active NTPD development and one of the reasons why I will
> not spend my own time/money on NTP WG: Just like the PPS-API WG, I
> expect it to be nothing but rubber stamping of the status quo with
> no real intention to let new research and results affect the existing
> code base.
>
>> You didn't read my message. The requirement to use a crafted discipline
>> algorithm applies only to an intermediate server with upstream sources
>> and downstream clients.
>
>
> It is still bogus to mandate one particular algorithm rather than
> set up requirements for the performance. A good place to start
> would be to document the pole/zero positions of the current code,
> something I have yet to see anywhere.
>



More information about the hackers mailing list