Re: [chrony-dev] System time offset bias

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Thu, Aug 20, 2015 at 08:25:33PM +1200, Bryan Christianson wrote:
> Even with all the improvements made to fixing the local offset, I'm still seeing a bias of about 1 usec (which is an order of magnitude better than where we started)
> 
> I presume this is the cumulative effects of function call overheads (both local to chronyd and system calls) made after we have measured time stamps with gettimeofday().

A source of the offset could be an error in the predicted_error as its
calculation assumes that the slew has infinite rate. Maybe it would
improve if you included the slew rate obtained from the kernel in the
calculation.

But are we really talking about fixing an offset comparable to the
resolution of the clock? :)

> I've been looking at using a bit of negative feedback and calculating the mean of offset_register as measured by get_offset_correction() and applying a small percentage of this mean offset to the predicted error in start_adjust(). The results are looking promising.

I don't know, I'd rather avoid adding a feedback loop if not
necessary. How will you determine which offsets should be included in
the average?

> Because get_offset_correction() is being called at random intervals, I don't think its correct to calculate the mean with a simple exponential moving average, but that a weighted rolling average taken over say 60 samples might be more appropriate. Please correct me if I'm wrong because an exponential mean is far simpler.

I'm not sure. You could try both and see if there is any improvement.

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