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

[Bryan Christianson <bryan@xxxxxxxxxxxxx>]

> On 11/08/2015, at 12:15 am, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
> 
> 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.

Thank-you. Its the only call I could find that passes offset_sd directly to the driver
> 
>> +{
>> +  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?

Yes. I realise any residual is picked up in the next cycle, but my thinking was to complete the update within a cycle in order to minimise the number of wakeups.

> 
> 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);

So this is estimating the contribution of local drift to offset_sd where C1 is an estimate of the proportion of local contribution?

> 
> 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.

I'm testing this at the moment with C1 = 0.1 (just a guess based on my drift of 22ppm and offset_sd between 20 and 150 usecs for the LAN ntp servers) and C2 = 0.5e-6 (i.e. a small fraction of my observed drift)

The LAN results look satisfactory with drift_removal_interval < 1.0 secs.
Local (NZ) based pool servers also seem to work OK with 0.9 < drift_removal_interval < 3
International (US) pool servers are also working OK - offset_sd around 5000usec and drift_removal_interval about 30 secs

I'll leave it running with US servers for a few hours to see how it behaves over a longer period.

-- 
Bryan Christianson
--
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.