William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ un...@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
On Mon, 2 Jul 2018, Pedro Côrte-Real wrote:
On Mon, Jul 2, 2018 at 2:46 PM, Miroslav Lichvar <mlich...@redhat.com> wrote:
That 100.0 is actually a limit for the estimated error in frequency
and is not related to the offset.
I see that now, sorry. Ignore that bit then.
The recommended configuration is supposed to minimize the number of
people complaining that NTP does not work. I agree that for most
people it would be better to completely disable stepping of the clock.
But those few that have a computer which for some reason can start
with system time far from the true time, it would be a big problem.
They would need to figure out what's going on and use the chronyc
makestep command to fix it. That's not a good user experience.
I think the real discussion then is the difference between adjustments
at boot time and adjustments at chrony startup time. Chrony startup
time may be early boot when stepping is not a problem but it may also
be after installing it on a running server when things may be
confused. If there was a way to say "only step when starting up at
early boot time when nothing important is running" then maybe that
would be ok.
If it is a running system, then the system should still be within 1 sec or
UTC, so this should be irrelevant. If not, it is up to you to decide if you
want to wait at least 10 times the offset (on Linux, much longer on Mac or
other OS) for it to get back to UTC, or if you want it to get to the right
time faster. If you do not want it to reset, then that is in your control.
Most people would get upset if a day after starting chronyd it was still not
showing the right time (eg if it was initially out by a day, for some reason)
I don't see a big difference between servers and desktops/laptops.
What matters is the RTC. On real HW it needs to be present, have a
battery, must not drift too much and the local/UTC setting must be
correct. Similar requirements apply to virtual machines. It needs to
work with suspend/resume and migrations.
The main difference I see between servers and desktops/laptops is that
servers may actually need to have a good clock of fail reliably.
But the clock is not good and for some reason you switched on chonyd when it
was not good. Is it more important to slowly slew the clock or to get it on
time as quickly as possible.
Whereas desktops/laptops are fine as long as the clock is reasonable
(I'd argue monotonic is important but maybe not even that).
Even if we could be assume that everything always works as expected,
someone or something would need to set the RTC for the first time.
When you bought a new server/desktop/laptop, did it always come with
the clock correctly set?
Being required to do an adjustment manually doesn't seem like a
problem but thinking about it I've probably relied on Ubuntu running
ntpdate in the past. These days, with interactive installers that
connect to the network having the installer ask if it should step the
clock would probably be ideal.
No, there is so so much junk pasted to the screen during installing that that
request would get lost in the noise and the clock would stay way out.
Pedro
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
