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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
