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.
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?
Thanks
Ed W
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
On 14/04/2011 19:20, john stultz wrote:
> On Thu, 2011-04-14 at 12:19 +0100, Ed W wrote:
>> 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.
OK, I have digested that and come to the conclusion that this might be a
little beyond what I can easily code up... Any chance of some hints to
get started from those that know what they are doing here?
Cheers
Ed W