Re: [RFC][PATCH] new timeofday core subsystem (v.A0)

George Anzinger
2004-09-04T00:08:28Z

john stultz wrote:
> Really quick: I'm off on vacation until Weds. Hopefully I've addressed
> in some way everyone's comments and my email box won't be stuffed when I
> return. I might peek in every once in awhile, though.
>
> Just one last response...
>
> On Fri, 2004-09-03 at 15:10, George Anzinger wrote:
>
>>john stultz wrote:
>>
>>>I feel trying to keep two notions of time, one in the timeofday code and
>>>one in the timer code is the real issue. Trying to better keep them
>>>synced will just lead to madness. Instead the timer subsystem needs to
>>>move to using monotonic_clock(), or get_lowres_timestamp() instead of
>>>using jiffies for its notion of time. Jiffies is just an interrupt
>>>counter.
>>
>>Well, there may be a better way. Suppose we change all the accounting code to
>>work with nanoseconds. That way when we do an accounting pass we would just add
>>what has elapsed since the last pass.
>
>
> Yep, that'd work too.
>
>
>>Still need some way to do user timers that are tightly pegged to the clock.
>
>
> I see that as just a problem of programming the timer interrupt
> generator. If you have a nanosecond (or as high as the best timesource
> on your system provides) resolution notion of time, then there is
> nothing to peg or tie the timer with. You simply just program it to go
> off every X nanoseconds. Should it be so inaccurate that it does not go
> off right at X nanoseconds, then you've hit a limit of the hardware.
> Pick a more accurate interval length, dynamically change your interval,
> or live with it. If the soft-timers use monotonic-clock() to determine
> when they expire, then you won't get accumulating drift (as
> monotonic-clock()is NTP frequency adjusted), only the minor jitter
> caused latency caused by the interrupt programming.
>
>
>>A thought I had along these lines was to program a timer for each tick. The PIT
>>is much too slow for this, but the APIC timers seem to be rather easy to
>>program. I am not sure how fast the access is but it can not be anything like
>>the PIT. Under this scheme we would use the monotonic clock to figure out just
>>how far out the next tick should be and program that.
>
>
> Yep, tickless systems also start being possible. We just have interrupts
> for scheduled events.
>
>
>>This could be modified to use repeating hardware if it is available. (What does
>>the HPET provide? Does it interrupt?) Since the APIC clock is not the
>>reference clock (the PIT & pm timer clock is) we would have to correct these
>>from time to time but that is rather easy (I do it today in HRT code).
>
>
> Don't know the details of interrupt generation, so I can't tell ya. I'm
> not sure I followed the correction bit?
>
>
>>This brings up another issue. We know what the PIT clock frequency is but not
>>what the TSC clock frequency. Currently we do a calibration run at boot to
>>figure this but I can easily show that this run consistently gives the wrong
>>answer (I am sure this has to do with the I/O access delays). If we are going
>>to use the TSC (or any other "clock" that is not derived from the PITs
>>14.3181818MHZ ital) we need both a way to get the correct value AND a way to
>>adjust it for drift over time. (Possibly this is the same thing.) Of course
>>this is all just x86 stuff. Other archs will have their own issues.
>
>
> Again, monotonic_clock() and friends are NTP adjusted, so drift caused
> by inaccurate calibration shouldn't be a problem the interval timer code
> should need to worry about (outside of maybe adjusting its interval time
> if its always arriving late/early). If possible the timesource
> calibration code should be improved, but that's icing on the cake and
> isn't critical.
>
Are you providing a way to predict what clock count provide a given time offset
INCLUDING ntp? If so, cool. If not we need to get this conversion right. We
will go into this more on your return.

Have fun.

> Again, thanks to everyone for the great feedback and discussion!
> -john
>

--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml