[ntp:hackers] Cool new stuff
kardel at ntp.org
Fri Jul 21 06:50:31 UTC 2006
David L. Mills wrote:
> 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.
> 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
While talking about debug levels shouldn't we consider classifying
(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.
More information about the hackers