linux-kernel - Re: Improved TSC calculation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 09 Dec 2011 13:01:32 +0000
From:	Ed W <lists@...dgooses.com>
To:	john stultz <johnstul@...ibm.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Improved TSC calculation

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/