Re: [chrony-dev] [PATCH] MacOS X add drift removal with corrected rounding

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, Jul 28, 2015 at 07:57:32PM +1200, Bryan Christianson wrote:
> ---
>  sys_macosx.c | 110 +++++++++++++++++++++++++++++++++++++++++++----------------
>  1 file changed, 80 insertions(+), 30 deletions(-)

What improvement in performance do you see with this patch?

> +    Adjustment started at T0
> +    Adjustment completed at T  (skew_time)
> +    Clock drifts during T to T1
> +
> +     ^    |\                |
> +     |    | \               |
> +     o    |  \            / |
> +     f    |   \         /   |
> +     f    |    \      /     |
> +     s    |     \   /       |
> +     e    |------\/---------|--
> +     t    T0      T         T1
> +     |    |<---- elapsed -->|
> +     v    |<-skew><-drift-->|

I'm trying to understand how this works. Is the assumption that at T
the offset of the clock is zero?

> +     From T0 to T  the clock is skewed at a rate of skewrate
> +     From T  to T1 the clock drifts as measured by current_frequency
> +
> +     Assume T and T1 are always greater than T0. Either or both could be less
> +     if the clock has been manually adjusted, but thats a one off aberration
> +     and will self correct in the next adjustment cycle.
> +
> +     Interval calculation is independent of the sign of the various offsets
> +     although signs must be taken into account when calculating the updated offset
> +
> +  */
> +
> +  skew_time = fabs(adjustment_achieved / skewrate); /* time during which adjtime() is active */
> +  drift_time = 0;
> +  if(skew_time < fabs(elapsed)) {
> +    /* previous adjtime() has completed - remaining time is free running */
> +    drift_time = fabs(elapsed) - skew_time;
> +  }
> +
> +  offset_register += current_freq * drift_time - adjustment_remaining;

Ok, so the difference to the removed code is that the interval 
which current_freq is multiplied with now doesn't include the time
when adjtime was active?

I think the current code is trying to account for the offset that is
gained when adjtime is active. For example, if the frequency offset of
the clock when adjtime is not active is 100 ppm and adjtime slews by
500 ppm, it will take 10 seconds to correct 5 milliseconds, but in
that time it will gain another millisecond of offset, which needs to
be corrected in the next adjtime call. The effective slew rate is 400
or 600 ppm depending on the sign of the offset.

Does your change still take this into account?

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