Messages in this thread | | | From | "Ulrich Windl" <> | Date | Thu, 09 Dec 2004 08:57:07 +0100 | Subject | Re: [RFC] New timeofday proposal (v.A1) |
| |
On 8 Dec 2004 at 15:36, john stultz wrote:
[...] > Take a look at the adjtimex man page as well as the ntp.c file from the > timeofday core patch. There are number of different types of adjustments > that are made, possibly at the same time. Briefly, they are (to my > understanding - I'm going off my notes from awhile ago): > o tick adjustments > how much time should pass in a _user_ tick
tick adjustments are considered obsolete, because if a lcok implementation (or hardware) is severly broken, users should reject using that stuff. Meaning: tick adjustments are ment to be set once in the life of a computer system. No continuous tuning.
> o frequency adjustments > long term adjustment to correct for constant drift),
Actually, you are compensating for a "tick problem" on a smaller scale (constant part), and variations caused by temperature, voltage, and others (variable part).
> o offset adjustments > additional ppm adjustment to correct for current offset from the ntp > server > o single shot offset adjustments > old style adjtime functionality > > Tick, frequency and offset adjustments can be precalculated and summed > to a single ppm adjustment. This is similar to the style of adjustment > you propose directly onto the time source frequency values. > > However, there is also this short term single shot adjustments. These > adjustments are made by applying the MAX_SINGLESHOT_ADJ (500ppm) scaling > for an amount of time (offset_len) which would compensate for the > offset. This style is difficult because we cannot precompute it and > apply it to an entire tick. Instead it needs to be applied for just a > specific amount of time which may be only a fraction of a tick. When we
Yes, that's the "precise" variant of implementing it. Poor implementations are just accurate to one tick.
> start talking about systems with irregular tick frequency (via > virtualization, or tickless systems) it becomes even more problematic. > > If this can be fudged then it becomes less of an issue. Or at worse, we > have to do two mult/shift operations on two "parts" of the time interval > using different adjustments. > > Its starting to look doable, but its not necessarily the simplest thing > (for me at least). I'll put it on my list, but patches would be more > then welcome. > > thanks > -john > > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |