Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Aug 2017 13:30:03 +0300
From:      Daniel Braniss <danny@cs.huji.ac.il>
To:        Ian Smith <smithi@nimnet.asn.au>
Cc:        Kevin Oberman <rkoberman@gmail.com>, Karl Denninger <karl@denninger.net>, stable@freebsd.org
Subject:   Re: issues with powerd/freq_levels
Message-ID:  <A58813CF-FAC4-477C-A441-8217325744A3@cs.huji.ac.il>
In-Reply-To: <20170802004343.T6737@sola.nimnet.asn.au>
References:  <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@sola.nimnet.asn.au> <CAN6yY1t5xYXMig0PSGn=Gdr=fOZJUBUYEGtXYxxJ9Q7R=z_kWw@mail.gmail.com> <20170802004343.T6737@sola.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help

> On 1 Aug 2017, at 20:45, Ian Smith <smithi@nimnet.asn.au> wrote:
>=20
> On Mon, 31 Jul 2017 12:03:27 -0700, Kevin Oberman wrote:
>> On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith <smithi@nimnet.asn.au> =
wrote:
>>=20
>>> On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote:
>>>=20
>>>> I am trying out PCengines latest apu2 boards, and I just noticed =
that
>>> with different Freebsd versions I get
>>>> different freq_levels, and so when idling, each box (have 5) has a
>>> different freq/temperature value, ranging
>>>> from 125/69.1C, 600/59.0C to 75/56.0C
>>>>=20
>>>> FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) =
tip:
>>> Mon Jul 31 09:36:33 IDT 2017
>>>> apu-4# sysctl dev.cpu.0.freq_levels
>>>> dev.cpu.0.freq_levels: 1000/980 800/807 600/609
>>>=20
>>> That looks about right.  On a Core2Duo (still on 9.3) I get:
>>> dev.est.1.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000
>>> dev.est.0.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000
>>> dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000
>>> dev.cpu.0.freq: 800
>>>=20
>>> But only because I'd added to /boot/loader.conf:
>>>=20
>>> hint.p4tcc.0.disabled=3D1
>>> hint.acpi_throttle.0.disabled=3D1
>>>=20
>>> which became the defaults sometime, maybe not before 11.0?  =
Otherwise
>>> mine would look more similar to the one below, with all 12.5% =
increments
>>> in frequency enabled, which doesn't actually save any power at all.
>>>=20
>>>> FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 =
21e9d1ca9b80
>>> (11) tip: Tue May 30 11:51:48 IDT 2017
>>>> apu-5# sysctl dev.cpu.0.freq_levels
>>>> dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 =
525/525
>>> 450/450 375/375 300/300 225/225 150/150 75/75
>>>=20
>>> Looks like either p4tcc or acpi_throttle is enabled?  See =
cpufreq(4).
>>> As above, these don't buy you anything but extra busyness for =
powerd.
>>>=20
>>> Also noticed that the (nice, low!) milliwatt figures for =
1000/800/600
>>> freqs are a bit different to the -stable one.  Slightly Different =
model?
>>>=20
>>>> FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) =
tip:
>>> Tue Jan 10 09:09:00 IST 2017
>>>> apu-1# sysctl dev.cpu.0.freq_levels
>>>> dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1
>>> 250/-1 125/-1
>>>=20
>>> And that looks like est(4) isn't enabled/attaching at all .. see =
dmesg
>>> on all of these for clues.
>>>=20
>>>> so, any ideas as to what is going on?
>>>=20
>>> Pure guesswork on experience with older versions, I'm not up to =
date.
>>>=20
>>=20
>> Very odd. Are all systems running identical CPUs and BIOSes? =
Identical
>> loader and sysctl configurations? Look at /var/rn/dmesg.boot for CPU
>> information. Is EST being detected? It used to be early in the boot
>> process, but is now fairly late. (In my case, about 2/3 through the
>> dmesg.boot file.
>=20
> Hi Kevin, it's been a while ..
>=20
> Danny, can you put up a verbose boot dmesg.boot of one(?) for a =
browse?=20
> Or maybe apu-4 and -1, if not all.  I'd expect error msgs on -1 =
anyway.
they are now available	at:
	http://www.cs.huji.ac.il/~danny/pcengines/ =
<http://www.cs.huji.ac.il/~danny/pcengines/>;
>=20
>> I have p4tcc and throttling explicitly turned off (which should now =
be the
>> default), but my Sandy Bridge Core i5 still shows:
>> dev.cpu.0.freq_levels: 2501/35000 2500/35000 2000/26426 1800/23233
>> 1600/20164 1400/17226 1200/14408 1000/11713 800/9140
>=20
> All truly available I see on more recent processors.  Certainly not =
1/8=20
> duty-cycle multipliers as p4tcc and maybe? acpi_throttle (not seen =
here)
>=20
>> The first is really bogus to indicate "turbo" mode.
>=20
> Usefully bogus, in that you can flag powerd to (in your case) -M 2500 =
to=20
> prevent it engaging "turbo" mode, as I do on my old Core2Duo, as =
advised=20
> by Warner years ago to avoid overheating on buildworlds and such - but=20=

> more recent incarnations of "turbo" are supposedly far more =
functional.
>=20
> Admittedly a digression .. mostly coming from wondering about data =
Karl
> posted in response, indicating different Cx levels available and so =
used=20
> by the latter 3 AP cores, which was news to me.  I'd like to know =
more,=20
> if only for gratuitous curiosity.  Others can tick their TL;DR box :)
>=20
>> Temperature is a totally separate issue. It is VERY sensitive to =
external
>> issue like airflow and position of the CPU in relation to other =
components
>> in the chassis Also, unless you have a lot of cores, you probably =
should
>> set both economy_cx_lowest and performance_cx_lowest to Cmax. Economy
>> should default to that, but  performance will not as that can cause =
issues
>> on systems with large numbers of cores, so is set to C2. Many such =
system
>> used to disable deeper sleep modes in BIOS, but I am way behind the =
times
>> and don't know about the current state of affairs. Certainly for =
systems
>> with 32 or fewer cores, this should not be an issue. In any case, Cx =
state
>> can sharply impact temperature.
>=20
> Indeed.  But as these are low-power devices already, it's likely less =
of=20
> a concern, but maximising efficiency and minimising stress never =
hurts.
>=20
>> Finally, the last case with power levels of -1 for all frequencies is
>> probably because the CPU manufacturer (Intel?) has not published this
>> information. For a while they were treating this as "proprietary"
>> information. Very annoying! It's always something that is not readily
>> available. Thi is one reason I suspect your CPUs are not identical.
>=20
> Hmm, bought as a batch, that sounds unlikely, though their BIOSes =
(ono)=20
> may vary, and would be worth checking on each - and BIOS settings, =
too.
>=20
> Danny, is powerd running on all these?  I doubt it would load on apu-1=20=

> as it stands. =20

it is working on the apu-1!

>                    Note these are 'pure' 1/8 factors of 1000, =
p4tcc-alike,=20
> and I think quite likely indicate that cpufreq(4) failed to =
initialise?=20
> debug.cpufreq.verbose=3D1 in /boot/loader.conf might show a clue, with =
a=20
> verbose dmesg.boot anyway.
>=20
> Later: oops, just reread Karl's message, where I was unfaniliar with=20=

> different CPUs showing different C-states, and noticing that despite=20=

> cpu0 showing C2(io) available, and cx_lowest as C2, yet it used 100% =
C1=20
> state, which was all that was available to cpu1 to 3.
>=20
> But then I twigged to Karl's hwpstate errors, so with 'apropos =
hwpstate'=20
> still showing nothing after all these years, along with other =
cpufreq(4)=20
> drivers, I used the list search via duckduckgo to finally find one (1)=20=

> message, which lead to one detailed thread (that I even bought into!)
>=20
> =
https://lists.freebsd.org/pipermail/freebsd-stable/2012-May/subject.html =
<https://lists.freebsd.org/pipermail/freebsd-stable/2012-May/subject.html>=

> =
https://lists.freebsd.org/pipermail/freebsd-stable/2012-June/thread.html =
<https://lists.freebsd.org/pipermail/freebsd-stable/2012-June/thread.html>=

>=20
> /hwpstate  Note the May one needs following by Subject, else it splits=20=

> into 5 separate threads (?)
>=20
> Which may be interesting to cpufreq nerds, but had me remember that=20
> hwpstate(0) is for AMD not Intel CPUs.  So now I'm totally confused :)
>=20
> Danny, do your results from Karl's sysctl listings agree with his?

yes, except mine seem to be running at a higher temperature.

thanks,
	danny
>=20
> cheers, Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A58813CF-FAC4-477C-A441-8217325744A3>