On 24.08.24 05:04, Harlan Stenn wrote:
On 8/23/2024 7:06 PM, Jochen Bern via dovecot wrote:
(As an example for why this is relevant: Several hundred deviations of 100 ms or more per day sum up to several 10+ seconds per day, if only they all are in the same direction, or several 115+ ppm.
Forward step or slew adjustments should be no problem.
Well, define "problem". The OP has a problem with the many log messages that *say* that the timescale slipped 100+ ms into the future (whether those actually happen to the system's *clock*, and if so, are triggered by the system's NTP sync, is unlikely-but-still-unclear IMHO), and Timo said that dovecot should then also try to counteract the offset for other still-running timeouts, which sounds like a problem waiting to happen *there* to me ...
ntpd refuses to do *slews* correcting by more than 500 ppm;
This is news to me.
Hmmmm. I checked that and a couple ntpd manpages, while the more current versions blame the 500 ppm limit on Unix kernels, the older ones say that
The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based.
I remember that *some* limit - not necessarily 500 ppm, but that was the value chosen - was a *necessary* requirement for the proof, and that ntpd used to be a stickler for protocol and limits as written. Did the latter change ... ?
(Anyway, I once had to sysadmin hardware that would flip-flop between IIRC -450 and +550 ppm from one bootup to the next, so I *am* perfectly sure that that was beyond the back-then ntpd's capabilities to adjust for. Its offset *kept growing* when they asked me to "fix its clock problem".)
If what we offer does not satisfy your requirements, please let me know and we'll find a way to improve things.
(Just to be perfectly clear here: No complaints from *me*. I'm firmly in the "hardware outside the ±100 ppm corridor is defective" camp.)
Kind regards,
Jochen Bern Systemingenieur
Binect GmbH