The new ntp.conf file format
Please add your comments following the appropriate point of discussion following the existing format (e.g. add your signature at the end of your comment and use
as a separator.) General Comments should go in the section set-up for them. Please add another discussion heading if needed.
Where should we allow each configurable item to be specified?
Allow configuration of (up to) N IPs for a given server/peer.
- Do we really need this for peers?
restrict handling easier?
- Automatic for every server/peer?
- Also see Bug #376
Improved logging/debug facility
- Overriding default settings for locking
ntpd in memory
- Also see Bug #220, Bug #477
There might be something to be said for a command-line override too, but that is getting "busy".
- 24 Jul 2004
Make "exit if things get rough" an option (Wolfgang Rupprecht)
Audio refclock variables
Make hardcoded values (volume, ???) in icom.c configurable here
Also see Bug #291
, Bug #406
and Bug #407
We should allow folks to override the defaults for the setup string, the connect timeout, etc.
I'd like to find a useful library that handled this, and I'd rather not re-implement "expect".
My preference would be a BSD-licensed thing, as opposed to a GPL thing.
- 10 Dec 2004
Minpoll,maxpoll driver/user preferences
Are you saying that if the max and min poll values are initialized in
the driver, they overwrite any ntp.conf server options? ...
But, doesn't that violate the least astonishment principle?
It would be nice to have the driver suggest baseline values
and have the user override them if desired...
I very much second that. I had issues with hard-coded minpoll
at the driver-29 (Trimble Palisade) so I had to keep a patch and
reapply it for every ntp version upgrade.
Greg, ...The maxpoll/minpoll values are initialized in newpeer()
in ntp_peer.c before the refclock code. It's the same with all
associations. You get to set it from the configuration file. While the
defaults are inappropriate for the ACTS driver, I'm reluctant to take
away the means to change the values. The user can't override the default
values in the driver either, unless as you suggested they are fixed...
The values from the command line are set by newpeer() before the
refclocks get ahold if it. It would be messy, to say the least, to do
this during driver initialization.
More options (fudge) for non-refclocks
I would very much like to see 'fudge time1' being applicable to
network reference servers. Like JohnPettitt
, I see a very predictive
and stable offsets for network peers due to an asymmetric cable connection.
It would be nice to expand the fudge to non-refclocks, but this requires
rewrite of the configuration code as well as changes in the remote
configuration protocol. This in turn requires an asynchronous DNS
implementation. Besides providing a broader fudge application, this
would provide a really neat automatic pool capability. Nothing wildly
difficulat about this, but really down and dirty. Previous broad hints
for help in this area haven't raised any hands.
I initially thought this would make more sense on a per-interface basis, but I can see that it might be more useful per-peer.
- 18 Feb 2005
Individual huff'n'puff buffers for each network reference
You correctly concluded the huffpuff is global, not association
specific. Naughty me; I intended to say that in the documentation, but
at least the ntpd page doesn't say that. I thought about doing it (only)
for the prefer peer. Do you have a preference?
The current assumption for huffpuff is that all reference clocks
are on the other side of a single network connection, and it is the
single 'last mile' line that gets into asymmetric congested state.
It clearly isn't the case for local reference clock like atom,
which have roundtrip delay of 0. More generally, it also
isn't so for other peers, each of them may have a differently
behaving network leading to it, and sometimes the congested
lines are on the remote server side.
The best solution would be for each peer to have
its own huffpuff buffer. Apart from costing some memory,
I don't think this is a heavy price to pay. If huffpuff
could be configurable (at least: enabled/disabled) individually
on each 'server' config line, so much the better.
Is this an issue for
or is it an issue for
itself? If the latter, please consider opening an "enhancement" request at http://bugs.ntp.isc.org
- 18 Feb 2005