On Mon, 31 Jul 2017 12:03:27 -0700, Kevin Oberman wrote:
> On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith <smithi at nimnet.asn.au>
wrote:
>
> > On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote:
> >
> > > 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
> > >
> > > 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
> >
> > 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
> >
> > But only because I'd added to /boot/loader.conf:
> >
> > hint.p4tcc.0.disabled=1
> > hint.acpi_throttle.0.disabled=1
> >
> > 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.
> >
> > > 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
> >
> > 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.
> >
> > Also noticed that the (nice, low!) milliwatt figures for 1000/800/600
> > freqs are a bit different to the -stable one. Slightly Different
model?
> >
> > > 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
> >
> > And that looks like est(4) isn't enabled/attaching at all .. see
dmesg
> > on all of these for clues.
> >
> > > so, any ideas as to what is going on?
> >
> > Pure guesswork on experience with older versions, I'm not up to
date.
> >
>
> 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.
Hi Kevin, it's been a while ..
Danny, can you put up a verbose boot dmesg.boot of one(?) for a browse?
Or maybe apu-4 and -1, if not all. I'd expect error msgs on -1 anyway.
> 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
All truly available I see on more recent processors. Certainly not 1/8
duty-cycle multipliers as p4tcc and maybe? acpi_throttle (not seen here)
> The first is really bogus to indicate "turbo" mode.
Usefully bogus, in that you can flag powerd to (in your case) -M 2500 to
prevent it engaging "turbo" mode, as I do on my old Core2Duo, as
advised
by Warner years ago to avoid overheating on buildworlds and such - but
more recent incarnations of "turbo" are supposedly far more
functional.
Admittedly a digression .. mostly coming from wondering about data Karl
posted in response, indicating different Cx levels available and so used
by the latter 3 AP cores, which was news to me. I'd like to know more,
if only for gratuitous curiosity. Others can tick their TL;DR box :)
> 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.
Indeed. But as these are low-power devices already, it's likely less of
a concern, but maximising efficiency and minimising stress never hurts.
> 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.
Hmm, bought as a batch, that sounds unlikely, though their BIOSes (ono)
may vary, and would be worth checking on each - and BIOS settings, too.
Danny, is powerd running on all these? I doubt it would load on apu-1
as it stands. Note these are 'pure' 1/8 factors of 1000, p4tcc-alike,
and I think quite likely indicate that cpufreq(4) failed to initialise?
debug.cpufreq.verbose=1 in /boot/loader.conf might show a clue, with a
verbose dmesg.boot anyway.
Later: oops, just reread Karl's message, where I was unfaniliar with
different CPUs showing different C-states, and noticing that despite
cpu0 showing C2(io) available, and cx_lowest as C2, yet it used 100% C1
state, which was all that was available to cpu1 to 3.
But then I twigged to Karl's hwpstate errors, so with 'apropos
hwpstate'
still showing nothing after all these years, along with other cpufreq(4)
drivers, I used the list search via duckduckgo to finally find one (1)
message, which lead to one detailed thread (that I even bought into!)
https://lists.freebsd.org/pipermail/freebsd-stable/2012-May/subject.html
https://lists.freebsd.org/pipermail/freebsd-stable/2012-June/thread.html
/hwpstate Note the May one needs following by Subject, else it splits
into 5 separate threads (?)
Which may be interesting to cpufreq nerds, but had me remember that
hwpstate(0) is for AMD not Intel CPUs. So now I'm totally confused :)
Danny, do your results from Karl's sysctl listings agree with his?
cheers, Ian