issues with powerd/freq_levels

Tue Aug 1 18:11:28 UTC 2017

On 8/1/2017 12:45, Ian Smith wrote:
> 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?
These are not Intel CPUs; they are an embedded AMD 64-bit CPU.

The specs on the one I have are:

  * CPU: AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with 64
    bit and AES-NI support, 32K data + 32K instruction cache per core,
    shared 2MB L2 cache.
  * DRAM: 2 or 4 GB DDR3-1333 DRAM
  * Storage: Boot from m-SATA SSD, SD card (internal sdhci controller),
    or external USB. 1 SATA + power connector.
  * 12V DC, about 6 to 12W depending on CPU load. Jack = 2.5 mm, center
    positive
  * Connectivity: 2 or 3 Gigabit Ethernet channels (Intel i211AT on
    apu2b2, i210AT on apu2b4)
  * I/O: DB9 serial port, 2 USB 3.0 external + + 2 USB 2.0 internal,
    three front panel LEDs, pushbutton
  * Expansion: 2 miniPCI express (one with SIM socket), LPC bus, GPIO
    header, I2C bus, COM2 (3.3V RXD / TXD)
  * Board size: 6 x 6" (152.4 x 152.4 mm) - same as apu1d, alix2d13 and
    wrap1e.
  * Firmware: coreboot <http://www.coreboot.org/> (please contact
    support at pcengines.ch for source code if desired).
  * Cooling: Conductive cooling from the CPU to the enclosure using a 3
    mm alu heat spreader (included).

The one I have here is a 2Gb RAM/2 IGB Ethernet interface unit.

They're surprisingly capable for their size, conductive cooling and
(especially) price.  As a firewall/VPN ingress point they perform
nicely.  I boot the one I have here from an SD card in a NanoBSD config
but you can stick a mSATA SSD (laptop-computer style) in the case and
boot from that if you want (I've tried it; the internal BIOS it comes
with boots from it just fine.)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2993 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20170801/7d311d1e/attachment.bin>