Re: Improved TSC calculation

[john stultz <johnstul@us.ibm.com>]

On Thu, 2011-04-14 at 12:19 +0100, Ed W wrote:
> Hi, Thanks for the new stable TSC calculation commit
> (08ec0c58fb8a05d3191d5cb6f5d6f81adb419798).
> 
> My situation is that I don't have a PM or HPET timer (x86 Alix board),
> and my requirements are embedded type use, but with only intermittently
> connected network/gps, so accurate timekeeping between reboots is
> important.
> 
> I had been experimenting with extending the existing PIT timer routines
> at boot, but I had the problem that it was taking 1s+ to get a very
> stable calculation (which is undesirable for my requirements), however,
> having spotted your commit it seems like a much more sensible solution.

Thanks!

> Before I try and hack probably an (inadequate) solution myself, do you
> have any thoughts on the best solution to extend your commit to non
> PM/HEPT machine?  My initial thought was to repeatedly call
> pit_calibrate_tsc() with an extended latch, looking for a stable
> solution (ie refactor native_calibrate_tsc() ).  Is this workable?
> Better ideas?

Oof. So with the PIT you can maybe utilize the second channel/counter,
using a largish long countdown to try to get a similar functionality.
The only big concern is that the timer interrupt hardware is always
problematic (every time we chanage our usage, some random chunk of
laptops seem to stop working). So whatever solution that works for you
might not be able to be generically deployed. But I think it could be
interesting and might be worth you giving it a shot.

I'd probably look at reworking tsc_refine_calibration_work, extending
the tsc_read_refs() code to also get PIT count values and then start the
long PIT countdown on the second channel before we
schedule_delayed_work.

thanks
-john