Re: ntp: Adjustment of time_maxerror with 500ppm instead of 15ppm

[Miroslav Lichvar <mlichvar@redhat.com>]

On Thu, May 08, 2025 at 12:45:13PM -0700, John Stultz wrote:
> Looking back through the commit history, we used to increment
> time_maxerror by (time_tolerance >> SHIFT_USEC), but all the way back
> in the git history (2.6.12, and seemingly back as far as 2.3?)
> time_tolerance was always set to MAXFREQ.

This 500 ppm increment goes all way back to the original nanokernel
implementation by David Mills, on which IIRC was based the Linux and
other systems' timekeeping code:
https://www.eecis.udel.edu/~mills/ntp/html/kern.html

I think the idea to use MAXFREQ (reported as tolerance in timex) was
to cover the case when the clock is not synchronized at all with the
frequency offset set to any value in the +/- 500 ppm range. The Linux
adjtimex also allows setting the tick length, which gives it a much
wider range of +/-10% adjustment, so that is not fully covered.

Changing the hardcoded rate to 15 ppm to match RFC5905 doesn't seem
like a good idea to me. The kernel doesn't know how well the clock is
synchronized and I'm sure in some cases it would be too small.

The best solution would be to add a new mode to adjtimex to make it
configurable, e.g. named ADJ_MAXERRORRATE and the actual value
provided in the timex tolerance field. For compatibility with existing
NTP/PTP clients the rate could be reset to the default 500 ppm on
every ADJ_MAXERROR setting. To get a reduced rate updated applications
could set both ADJ_MAXERROR and ADJ_MAXERRORRATE at the same time.

-- 
Miroslav Lichvar