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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, Aug 11, 2015 at 05:18:47PM +1200, Bryan Christianson wrote:
> > 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.

It would be nice to have that too. But shouldn't it be rather a
function of the offset which was set by the last adjtime() call
instead of the estimated maximum error to the reference?

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

Ideally, if adjtime() reports the remaining offset accurately (and
there is no adjtime() offset lost or applied twice), the absolute
value of the drift should have no effect on the offset_sd value. The
source tracking works with the cooked timestamps and should be more or
less independent from any corrections that are currently applied to
the local clock. It's the job of the driver to hide them from the
upper layers.

I meant the C1 constant as a ratio between the maximum acceptable
offset of the clock that is gained between adjtime() updates and the
estimated error in the source tracking (including source combining,
etc).

If the clock is drifting by 10 ppm and the tracking of the source says
it's good only to 100 us, I think it would be ok to allow the clock to
drift between adjtime() updates by 25, 50, or maybe even 100 us. The
overall error of the clock won't be significantly worse than it would
be with a very short interval keeping the adjtime() offset within few
microseconds.

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

Is that with just one source or multiple sources (i.e. combining
enabled)? It would be nice if the update interval was in a typical
case with multiple pool.ntp.org servers at least 5-10 seconds long.

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