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
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>
> On 1 Aug 2017, at 20:45, Ian Smith <smithi at nimnet.asn.au> 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.they are now available at: http://www.cs.huji.ac.il/~danny/pcengines/ <http://www.cs.huji.ac.il/~danny/pcengines/>> >> 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.it is working on the apu-1!> 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-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> > > /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?yes, except mine seem to be running at a higher temperature. thanks, danny> > cheers, Ian