Gary E. Miller <g...@rellim.com>: > Yo All! > > I pulled git head, running it now on a server in place of chronyd. > > Seems to work OK. I'll keep an eye on it.
That's valuable feedback, seeing as I just performed the major surgery
of removing Autokey.
> I really like the chronyd socket interface over the SHM one. The user is
> not playing with magic numbers.
I'll take some convincing on this. Yes, the SHM interface is cryptic but
the last thing we need is jitter added by buffer management in the
socket layer. We don't need the additional complexity or attack surface,
either; adding yet another interface would be going in the exact opposite
direction from where I'm trying to take us.
> 'ntpq -p' is user hostile compared to 'chronyc sources'. chronyc adds
> units to the display, so you do not have to keep referring to them
> manual, and it makes it easy to deal with jitter and delay that
> varies by orders of magnitude.
I think you have a really strong point here. I'm adding your quote to
devel/TODO. It might not happen until we rewrite ntpq in
Python, though.
> And last, but not least, ntpd takes way, way, way longer to converge
> than chronyd. Which is why on the fly reconfiguation in ntpd is SO
> important. Last thing you ever want to do is restart ntpd.
>
> Right now, after 10 mins, ntpd has 2,000 times the jitter as chronyd had
> when I turned it off.
Mark and Daniel and I would prefer strongly to get rid of on-the-fly
reconfiguration entirely. It's a complicated hack leading to chronic
security issues. Mark has expressed a preference (with which I
strongly agree) for the only reconfig method to be "you SIGHUP the
daemon and it rereads its config".
Do we have to live with long convergence times? Do you have any theory
about what causes this and how it can be fixed?
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
signature.asc
Description: Digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
