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

[john stultz]

On Wed, 2005-08-17 at 02:28 +0200, Roman Zippel wrote:

> Let's look at the example patch below. I played a little with some code 
> and this just demonstrates an accurate conversion of the tick/freq values 
> into the internal values in ns resolution. It does a little more work 
> ahead, but the interrupt code becomes simpler and most important it 
> doesn't require any expensive 64bit math and you can't get it much more 
> accurate than that. The current gettimeofday code for tick based sources 
> is really cheap and I'd like to keep that (i.e. free of 64bit math). The 
> accuracy can and should be fixed (the change to timespec wasn't really a 
> major improvement, as it introduced new rounding errors).

Hmm. It could really use some comments, but it looks interesting. Let me
continue reading it and play around with it some more. 

> The other thing the example demonstrates is the interface from NTP to 
> timer code. The NTP code provides the basic parameters and then leaves it 
> to the clock implementation how they apply. The adjustment and phase 
> variables are really private variables. 

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?

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


thanks
-john


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