Re: [chrony-dev] [PATCH] MacOS X - Dynamic drift removal interval

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Thu, Aug 06, 2015 at 08:25:59PM +1200, Bryan Christianson wrote:
> Use the kernel slew rate amd measure drift to estimate the time required to compensate
> for the maximum error observed in the most recent sample. Use this time as the interval
> between drift removal updates until the next sample is received.

> +static void
> +set_sync_status(int synchronised, double est_error, double max_error)

Using the sync status driver function for this is a nice idea.

> +{
> +  drift_removal_interval = DRIFT_REMOVAL_INTERVAL;
> +
> +  if (!synchronised) {
> +    return;
> +  }
> +
> +  if (max_error > 0.0 && fabs(current_freq + kernel_slewrate) >= 1.0e-9) {
> +    drift_removal_interval = fabs(max_error / (current_freq + kernel_slewrate));
> +    drift_removal_interval = MAX(drift_removal_interval, DRIFT_REMOVAL_INTERVAL_MIN);
> +  }
> +}

Hm, it's not clear to me why is the interval a function of
kernel_slewrate and max_error. Is that intended for the case when a
large offset is being corrected and to not make unnecessary updates
before the offset reaches zero?

I was thinking something more for the case when the clock is already
close to zero, set the interval as long as the offset of the clock to
the tracked NTP time stays below est_error between the adjtime()
updates.

Something like this:
drift_removal_interval = C1 * est_error / (fabs(current_freq) + C2);

where C is some constant between 0.0 and 1.0 and C2 is maybe 1 ppm to
prevent getting inf or nan when current_freq is very close to zero.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.