Re: clocksource

Roman Zippel
2006-06-16T15:33:55Z

Hi,

On Thu, 15 Jun 2006, john stultz wrote:

> I've also been working on improving the adjustment algorithm. Paul
> Mckenney enlightened me to the established concepts in control theory, I
> started reading up on PID control (see:
> http://en.wikipedia.org/wiki/PID_controller ). While I have understood
> the basic concept, it was useful to read up on it. I've tried to rework
> the adjustment code accordingly.
>
> The method I came up with is really just P-D (proportional-derivative)
> control, but that should be ok since the adjustments are all linear so I
> don't think the integral control is necessary (control theorists can
> pipe in here).

This makes it more complex than necessary. AFAICT this controller
calculates the adjustment solely based on the current error, but we have
more information than this, which make the current error rather
uninteresting.
We know the clock frequency and the NTP frequency so we can easily
precalculate, how the error will look like at the next few ticks. Based on
this we can calculate how we have to adjust the clock frequency to reduce
the error. Overshooting is also not a real problem as long as the absolute
error gets smaller.

An important point about the last patch is not just robustness but also
speed, it tries to keep the fast path small, which is basically:

interval = clock->cycle_interval;
if (error > interval / 2) {
adj = 1;
if (unlikely(error > interval * 2)) {
...
}
} else if (error < -interval / 2) {
adj = -1
interval = -interval;
offset = -offset;
if (unlikely(error < interval * 2)) {
...
}
} else
return;

clock->mult += adj;
clock->xtime_interval += interval;
clock->xtime_nsec -= offset;
clock->error -= interval - offset;

You'll need a very good reason to do anything more than this for small
errors and I would suggest you start from something like this, as this is
the very core of the error adjustment.

bye, Roman