Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)

[Roman Zippel]

Hi,

On Tue, 16 Aug 2005, john stultz wrote:

> If they are private clock variables, why are they in the generic
> timer.c? Everyone is using it in exactly the same way, no?  Why do you
> oppose having the adjustment and phase values behind an ntp_function()
> interface?

These values belong to the clock, NTP specifies the speed of the clock via 
tick/frequency, these variables specify the current state of the clock. If 
we assume there is only one system clock, we need only one set of those, 
so leaving them in timer.c doesn't really hurt. How these variables are 
updated depends on the clock, so separating them doesn't make much sense.

> Maybe to focus this productively, I'll try to step back and outline the
> goals at a high level and you can address those. 
> 
> My Assumptions:
> 1. adjtimex() sets/gets NTP state values
> 2. Every tick we adjust those state values
> 3. Every tick we use those values to make a nanosecond adjustment to
> time.
> 4. Those state values are otherwise unused.
> 
> Goals:
> 1. Isolate NTP code to clean up the tick based timekeeping, reducing the
> spaghetti-like code interactions.
> 2. Add interfaces to allow for continuous, rather then tick based,
> adjustments (much how ppc64 does currently, only shareable).

Cleaning up the code would be nice, but that shouldn't be the priority 
right now, first we should get the math right.
I looked a bit more on this aspect of your patch and I think it's overly 
complex even for continuous time sources. You can reduce the complexity 
by updating the clock in more regular intervals. 

What basically is needed to update in constant intervals (n cycles) a 
reference time controlled via NTP and the system time. The difference 
between those two can be used to adjust the cycle multiplier for the next 
n cycles to speed up or slow down the system clock.
Calculating the offset in constant intervals makes the math a lot simpler, 
basically the current code is just a special case of that, where it 
directly updates the system time from the reference time at every tick.
(In the end the differences between tick based and continuous sources may 
be even smaller than your current patches suggest. :) )

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/