Re: Wonky NTP startup and the incremental-configuration problem

2016-06-26 Thread Hal Murray
An alternative option would be to implement rereading ntp.conf. For each line in ntp.conf, there are 3 possibilities. It's new or the value has changed, nothing has changed, or the item was dropped. The latter is the tricky case. The idea is to save a parsed copy of the old ntp.conf. As the

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-26 Thread Eric S. Raymond
Heads up, Mark! Achim Gratz : > > It would be better for code verifiability and security if the > > only source of configuration information for the daemon were the > > ntp.conf file. (We can't quite get there due to the requirement > > to store drift state, but closer would be better.) > > If y

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-13 Thread Mark Atwood
Hello Achim, I do like the idea of rich but simple signal semantics. We will have to talk it out more here in devel@ ..m On Fri, Jun 10, 2016 at 11:05 AM Achim Gratz wrote: > Eric S. Raymond writes: > > ntpq has dangerous operations that tweak parameters of the time-sync > > algorithms on t

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-10 Thread Achim Gratz
Eric S. Raymond writes: > ntpq has dangerous operations that tweak parameters of the time-sync > algorithms on the fly - operations that can be triggered remotely. Or so I > gather from things Hal Murray has said; my outside view is weak here, > I've never explored those operations. In the standar

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-10 Thread Eric S. Raymond
Jay Maynard : > I do have an Alpha with Tru64, and would be happy to lend it to the > project. It'll be a few days before I can attempt to bring it up. It hasn't > run in something like 10 years. Thanks. Hal Murray suggested we use an Alpha for comparative profiling. He'll be on vacation for a we

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-10 Thread Daniel Poirot
When faced with the exciting task of porting RTI's DDS real-time, Ethernet publish/subscribe middleware to OpenVMS for the USAF JSTARS project, I turned to both eBay (ES40) and FreeAXP. Performance on the Alpha emulator was faster than the real hardware and certainly suitable for development and un

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-10 Thread Eric S. Raymond
Hal Murray : > > e...@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 passwor

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-10 Thread Hal Murray
e...@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 >

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-10 Thread Eric S. Raymond
(Jay: You can skip down to where it says "DEC Alpha".) Hal Murray : > > e...@thyrsus.com said: > > ntpq has dangerous operations that tweak parameters of the time-sync > > algorithms on the fly - operations that can be triggered remotely. Or so I > > gather from things Hal Murray has said; my out

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-10 Thread Hal Murray
e...@thyrsus.com said: > ntpq has dangerous operations that tweak parameters of the time-sync > algorithms on the fly - operations that can be triggered remotely. Or so I > gather from things Hal Murray has said; my outside view is weak here, I've > never explored those operations. ntpq can be u

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-09 Thread Eric S. Raymond
Mark Atwood : > It looks like there is no obviously good route forward. > > My first inclination is to change ntpsec to do what chrony does re saving > the drift stats, and once we see that NTPsec can restart converge roughly > as well as chrony, we rip out the runtime conf code. Maybe even use t

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-09 Thread Mark Atwood
It looks like there is no obviously good route forward. My first inclination is to change ntpsec to do what chrony does re saving the drift stats, and once we see that NTPsec can restart converge roughly as well as chrony, we rip out the runtime conf code. Maybe even use the same filesystem file

Re: Wonky NTP startup and the incremental-configuration problem

2016-06-09 Thread Gary E. Miller
Yo Eric! On Thu, 9 Jun 2016 16:02:28 -0400 (EDT) e...@thyrsus.com (Eric S. Raymond) wrote: > There are two major questions here: > > 1. Why is convergence from a standing start so slow? Two issues, I'll be vague as I don't know better: a. restarting perturbs the system, sometimes badl

Wonky NTP startup and the incremental-configuration problem

2016-06-09 Thread Eric S. Raymond
Heads up, Mark. Strategic issue being raised here. Gary Miller says ntpd has a tendency to go nuts when restarted and converges on good time only slowly, sometimes taking 24-48 hours. This is a performance problem in itself, which needs to be high up on the list to be attacked. But it's also a