On Mon, May 13, 2024 at 04:00:33AM -0700, Bill Unruh wrote: > > On Mon, 13 May 2024, Feng Tang wrote: > > > [CAUTION: Non-UBC Email] > > > > Hi Miroslav Lichvar, > > > > On Mon, May 13, 2024 at 08:19:07AM +0200, Miroslav Lichvar wrote: > > > On Mon, May 13, 2024 at 09:02:31AM +0800, Feng Tang wrote: > > > > So my thought is, since user already chose to trust 'chrony', and > > > > when chrony has more realiable NTP time source, 'chrony' can help to > > > > correct the 'wrong date' set by user with the right time, practically > > > > 'rejecting' the huge time jump set by users. > > > > > > chronyd is trying to correct the clock, but a typical default > > > configuration provided with distro packages allows steps only on > > > start, so the ~10% slew can take very long time. > > > > Yes, exactly. In the above case, we saw the system time was compensated > > very slowly. > > It slews at 1 sec per 10 sec. if the clock is way out.
Got it, thanks > > > > > > > > The user would need to allow steps at any time. See this answer in > > > the FAQ: > > > https://chrony-project.org/faq.html#_is_chronyd_allowed_to_step_the_system_clock > > > > This works great in my test and the issue can't be reproduced. Many > > thanks for the hint! > > BUT you have to tell you users NOT to change the clock on their own. DO NOT > USE date to change the clock. If your users are going to do idiotic things > there is nothing you can do to correct all of their idiocies. Do not do it "as > a test" It is not a test. Nothing will ever make the clock suddeny jump > time. NOt allowing your clocks to jump may well produce worse things that > you are > complaining of now. Sure, will communicate about that. Thanks, Feng -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
