Re: [RFC] New timeofday proposal (v.A1)

[Ulrich Windl]

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