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

[George Anzinger]

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@xxxxxxxxxx
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

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