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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Wed, Aug 05, 2015 at 10:33:12PM +1200, Bryan Christianson wrote:
> I had a look at this method and tried a few others as well with no success. Then I realised that at the end of stop_adjust() we have:
> 
> offset_register += current_freq * elapsed_plus_adjust - adjustment_remaining;
> 
> Now, when the system is stable, adjustment_remaining will be small and elapsed_plus_adjust will be close to DRIFT_REMOVAL_INTERVAL (1 second) when the drift removal timer fires. On this machine the clock slews at 2ms / second and the adjtime() has completed in just a few 10s of usecs. So offset_register will contain a value close to current_frequency, which is what I am observing.

I think that's how it's supposed to work.

> This also explains why using DRIFT_REMOVAL_INTERVAL of 0.1s reduces the offset significantly. We make more frequent calls to adjtim() and consequently less time is spent with the clock free running and elapsed_plus_adjust has a smaller value.

That makes sense. The precompensation I was thinking was about moving
the mean offset closer to zero. For example, if the clock has a drift
of 100 ppm, the offset would be moving somewhere around around 0 +/-
50 microseconds, instead of 50 +/- 50 microseconds.

Something like this (not tested):

@@ -119,7 +119,7 @@ start_adjust(void)
   }

   UTI_DiffTimevalsToDouble(&elapsed, &T1, &T0);
-  accrued_error = elapsed * current_freq;
+  accrued_error = (elapsed + DRIFT_REMOVAL_INTERVAL / 2.0) * current_freq;

   adjust_required = - (accrued_error + offset_register);


> This suggests we should probably look at your idea of making DRIFT_REMOVAL_INTERVAL dynamic, although I am not sure what the criteria would be for adjusting it. Possibly an initial value of 1.0s, a minimum interval of 0.1s and a maximum of 4.0s (1/2 the minimum poll period).

Dynamic drift removal interval would allow us to control the maximum
offset. Maybe it could be even done without a fixed maximum interval.
A suitable interval could be determined from the drift and the offset
sd value (or possibly the correction rate parameter passed to the
accrue_offset() driver function). If we know the tracked NTP time is
good only to 1 millisecond and the drift of the clock is just 5 ppm,
allowing the offset to reach millisecond by setting the interval to
200 seconds would still be acceptable I think.

This could help with power saving when using (distant) public NTP
servers. Isn't the ntpd in Mac OS X patched to avoid waking up too
frequently?

> One possibility would be to make adjustments by 10% (or some other value between 0 and 1) depending on the value of adjustment_remaining - i.e. run drift removal less frequently if adjustments are not completing and more frequently otherwise. Might need to use some sort of filtering to prevent toggling of the value every other update.

Wouldn't that make the interval too short in most cases?

> 	if(adjustment_remaining != 0) {
> 		drift_removal_interval = MIN(drift_removal_interval * 1.1, MAX_DRIFT_REMOVAL_INTERVAL)
> 	} else {
> 		drift_removal_interval = MAX(drift_removal_interval / 1.1, MIN_DRIFT_REMOVAL_INTERVAL)
> 	}

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