Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Jul 2008 12:12:09 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Nate Lawson <nate@root.org>
Cc:        Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, freebsd-acpi@FreeBSD.org
Subject:   Re: HP/Compaq nx6325 clock "jumping around"
Message-ID:  <20080705120027.G12725@delplex.bde.org>
In-Reply-To: <486E4DE7.60807@root.org>
References:  <20080702191827.GK1469@uriah.heep.sax.de> <20080703145049.S6189@delplex.bde.org> <486E4DE7.60807@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 Jul 2008, Nate Lawson wrote:

>> On Wed, 2 Jul 2008, Joerg Wunsch wrote:
>> ...
> Bruce Evans wrote:
>> I know of the following bugs in time on nx6325:
> ...
>
> This reminds me -- the algorithm for estimating the cpu frequency needs 
> improvement.  You had a patch you sent me that reduced its error by a lot. 
> Would you commit it?

I'm further than ever from committing this, since I'm not set up for svn.

I never merged this to the kernel.  Running it in userland on more SMP
machines shows the expected problems from the CPU not being pinnable in
userland.

>> dev.cpu.0.freq: 1985
>> dev.cpu.0.freq_levels: 1985/-1 1736/-1 1488/-1 1240/-1 992/-1 744/-1 496/-1 
>> 248/-1
>> 
>> Once I used some performance/power-reduction config and got a list like 
>> yours.
>> 
>> 1985 actually gives 1995 MHz.
>
> Your freq estimation patch does better than this.

Aren't the above frequencies just read from acpi read-only data?

I forgot to mention another MI problem with cpu_ticker frequency
recalibration: its sanity checks don't detect even the enormous transient
garbage caused by stopping clocks.  Apparently all the clocks used in
the sanity checks are stopped too synchronously.  Otherwise, the
recalibration is very accurate.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080705120027.G12725>