Message-ID: <1323456919.4078.23.camel@work-vm>
Date:	Fri, 09 Dec 2011 10:55:19 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Ed W <lists@...dgooses.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Improved TSC calculation

On Fri, 2011-12-09 at 13:01 +0000, Ed W wrote:
> 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

So, I guess what have you tried and where have you run into troubles?

I really don't have too much time to dig in on this particular issue,
but I'd suggest looking at pit_calibrate_tsc() in arch/x86/kernel/tsc.c
and considering how it might be extended to better improve accuracy.

So part of the difficulty with a timer based approach, is that the PIT's
lowest freq is something like 18hz, which is ~50ms. So you can't really
get a very good sampling interval over that time.

You might be able to do something funky where you set a timer for 1
second out, and sample the PIT/TSC combo, and then sample it again when
the timer fires, and knowing how many times the PIT should have wrapped,
you could probably get a sense of the TSC freq. However, I worry that
might be a bit fragile.

If you're looking for info on how to program the PIT, check out the
wikipedia page and the external links from:
	http://en.wikipedia.org/wiki/Intel_8253

Sorry I've not been of much help here! Let me know if you have any
patches you want me to look at or have any more concrete questions.

thanks
-john


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

Powered by blists - more mailing lists