[ntp:hackers] Cool new stuff

Frank Kardel kardel at ntp.org
Fri Jul 21 06:50:31 UTC 2006


David L. Mills wrote:

> Guys,
>
> We are in the final stages of testing radically new stuff:
>
> 1. Remote configuration/mobilization/demobilization at any time using 
> ntpq. The commands are identical to those in the configuration file 
> now. In principle, it is possible to bring up a raw daemon and 
> configure it entirely from ntpq.

a very welcome feature!
 

>
> As you might expect, the configuration code is almost completely 
> gutted and the ntpdc remote configuration no longer works. On the 
> other hand, al lot of things that were once applicable to all 
> associations can now be applied on a per-association basis. At this 
> time the command syntax and semantics support the current 
> interpretation. The plan is to provide a command line switch to enable 
> the legacy interpretation and whatever new interpretation seems 
> advised. This is expected to evolve using C-type syntax with curly 
> brackets and semicolons.

>
>
> The syntax change will be considered radical by many and the end of 
> ntpdc remote configuration will be considered evil by some. The ntpdc 
> program continues to be supported but without the capability for 
> remote configuration.
>
This this is finally the end that we need to tunnel parameters through 
time1/2  and the flags. Finally we can have proper syntax for the
implemented semantics. Good!

> Lots of things haven't been thorougly tested and several improvements, 
> like the ability to read configuration files by ntpq, need to be on 
> the todo list. However, Sachin Kamboj, the ace implementer of this 
> stuff, is no longer supported by contract and is volunteering his own 
> time. Probably the best way to proceed is to bring up a parallel 
> version for a very short breaking-in test and then switch it to 
> ntp-dev. Sachin is now doing this with diffs, which simplifies the 
> switchover. I'd like the autoconfigurus to look at it and see if the 
> syntax tree construction and merge can be automated.
>
> If you have thoughts about this, please honk. When ready for test I 
> will aadvise. Probably a ntp-new directory on deacon:/backroom.
>
> Dave
>
> P.S. Testing has been complicated by intermittent huge spasms of debug 
> messages apparently emitted by the interface code. Can this be 
> attentuated or moved to a higher -d level? DLM
>
will move to a higher debug level (like >= 3) and remove some output. 
These spams are generated by the other
cool new stuff that makes ntpd cope with changing interface 
configurations and thus enables it the be a well
behaved citizen in the mobile world or cope with "Zwangsgtrennung" (sick 
concept by ISPs for you to get forcibly a new
IP address).
While talking about debug levels shouldn't we  consider  classifying 
debug  levels
(maybe like the logconfig command)  so we can selectively crank up  
debug for io/loopfilter/clockselection/crypto/peers ?
I have basically the same problem when debugging the i/o engine - I get 
swamped by all the other areas of the code.

Frank


More information about the hackers mailing list