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

[Ulrich Windl]

On 16 Aug 2005 at 18:17, john stultz wrote:

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

One of the greatest mistakes in the past which still affects us now was the 
decision to piggy-back ntp_adjtime and ntp_gettime on top of adjtime() and thus 
creating adjtimex(). Only to save a system-call number or two. WE REALLY SHOULD 
GET RID OF THAT going back to Linux 0.something.

> 2. Every tick we adjust those state values

... which require it. 

> 3. Every tick we use those values to make a nanosecond adjustment to
> time.

...or even more frequent. In my code I tried to scale the tick interpolation as 
well, thus effectively making adjustments even within timer ticks (so far the 
theory...). I was assuming however that ticks and interpolation clocks are derived 
from one single source and would "float" the same way relative to each other.

> 4. Those state values are otherwise unused.

What is "otherwise"? Outside the "NTP clock model", or "between ticks"?

> 
> Goals:
> 1. Isolate NTP code to clean up the tick based timekeeping, reducing the
> spaghetti-like code interactions.

First you need a new clock model that's compatible with NTP. Then you can consider 
how to implement the NTP stuff. So the clock even without NTP has to be strictly 
monotonic for any interval it is read, be it nanoseconds, microseconds, 
milliseconds, seconds, minutes, hours, days, ... The clock delta (=increase of 
time) over time should be as constant as possible (i.e. time shouldn't go up like 
stairs).

> 2. Add interfaces to allow for continuous, rather then tick based,
> adjustments (much how ppc64 does currently, only shareable).

Adjustments to the clock _model_ are asynchronous by definition, while adjustments 
to the clock itself are, well, periodic. Whatever the period.

Maybe this helps and can be agreed on.

Regards,
Ulrich

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