esr at thyrsus.com said:
>> ntpq can be used to tweak things, but it takes a password.
>> I've never used it that way.
> And if *you* haven't...I begin to wonder if 99% of the userbase even knows
> this feature exists.
> I'm sorely tempted to just rip everything password-protected out of ntpq and
> server side both, muttering "security" if we get any pushback.
There is a command line switch to write stuff out. There is a script that
uses it to check the parser. We could probably find some other way to do
that.
> Hal: Do you think we'd get any pushback?
Not from me, but there might be a few people out there who use it.
Anybody on this list use it?
esr at thyrsus.com said:
> I'm not arguing either point, but it would help me to know *why* you're sure
> it won't help with system crashes. If my mental model isn't wildly off it
> ought to help with any outage sufficiently short for propagation delays from
> up-stratum server to remain similar.
If the system crashes you don't get a chance to save state. Maybe I missed
your original idea:
> How it should work is that there is just one way to hack your
> configuration, modifying ntp.conf, and restarting the daemon to
> reread it is a low-cost operation that produces only transient
> synchronization glitches.
How does that help crash recovery?
esr at thyrsus.com said:
> I'd like to know that too. If the non-g mode isn't wandering all over the
> park that is valuable information for characterizing the bug.
I'll be surprised if non -g works any better. It's role is to allow one big
jump in case the battery in your RTC has failed or things like that.
esr at thyrsus.com said:
> It seems to me that both burst and iburst are in serious need of being
> better documented. Would you do something about thst, please?
The existing documentation is much better than I could write. Have you
looked at it?
Start with docs/rate.txt and docs/poll.txt
You can learn a lot from the rate limiting stuff. It's carefully tuned to
work with iburst and burst.
--
These are my opinions. I hate spam.