Re: Improved TSC calculation

[Ed W <lists@wildgooses.com>]

On 14/04/2011 19:20, john stultz wrote:
> 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
>

Hi John

I don't suppose you ever gave any thought to looking into this
yourself... :-)

I have had a poke, but I'm way out of my depth trying to figure out a
good solution. 

For reference my goal was to get a stable TSC calculation for my
PCEngines Alix boards, which are basically popular, low cost x86
compatible boards, but without HPET or PM.  I rather want to use them as
way to get more reliable Stratum 1 NTP servers out in the wild -
hopefully by documenting them as a very low cost solution to pair with a
GPS.  Having them somewhat clock stable with respect to reboot would be
handy

It's a big ask, so understand that you are probably going to discard
this email

Thanks for listening and your advice so far

All the best

Ed W