Re: CPU frequency doesn't drop below 1200MHz (like it used to)
On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote: > On Fri, May 22, 2015 at 8:19 PM, Ian Smith wrote: > > On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote: > > > On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko wrote: [..] > >> Try changing the options in /boot/device.hints > >> hint.acpi_throttle.0.disabled="0" > >> hint.p4tcc.0.disabled="0" > > > > > Thanks, those also fixed powerd(8) for me that stopped working after > > > upgrading to stable/10 from releng/10.1. Why are those setting > > > suddenly needed now? > > > > > > -Kimmo [..] > > Can you say exactly in what way powerd stopped working then? > > Powerd(8) complained (excerpt from dmesg -a): > > Starting powerd. > powerd: no cpufreq(4) support -- aborting: No such file or directory > /etc/rc: WARNING: failed to start powerd > > Putting those two settings in loader.conf and rebooting fixed the > problem and powerd started working again apparently because cpufreq(4) > device was available again. Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus powerd - work for you, then it seems likely that you do not have EST enabled in your BIOS. Or at least, we've seen another instance where that was the case, which was fixed by enabling EST (or however your particular BIOS refers to it .. AMD for example use different terms). What CPU is this? In what machine? If EST (ono) IS enabled in your BIOS, this needs further investigation. As is, powerd may be running, but it's doing so highly inefficiently; refer to Stefan, Adrian and Kevin's responses for details. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CPU frequency doesn't drop below 1200MHz (like it used to)
On Sat, May 23, 2015 at 10:00 AM, Ian Smith wrote: > On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote: > > On Fri, May 22, 2015 at 8:19 PM, Ian Smith wrote: > > > On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote: > > > > On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko wrote: > [..] > > >> Try changing the options in /boot/device.hints > > >> hint.acpi_throttle.0.disabled="0" > > >> hint.p4tcc.0.disabled="0" > > > > > > > Thanks, those also fixed powerd(8) for me that stopped working after > > > > upgrading to stable/10 from releng/10.1. Why are those setting > > > > suddenly needed now? > > > > > > > > -Kimmo > [..] > > > Can you say exactly in what way powerd stopped working then? > > > > Powerd(8) complained (excerpt from dmesg -a): > > > > Starting powerd. > > powerd: no cpufreq(4) support -- aborting: No such file or directory > > /etc/rc: WARNING: failed to start powerd > > > > Putting those two settings in loader.conf and rebooting fixed the > > problem and powerd started working again apparently because cpufreq(4) > > device was available again. > > Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus > powerd - work for you, then it seems likely that you do not have EST > enabled in your BIOS. Or at least, we've seen another instance where > that was the case, which was fixed by enabling EST (or however your > particular BIOS refers to it .. AMD for example use different terms). > > What CPU is this? In what machine? > > If EST (ono) IS enabled in your BIOS, this needs further investigation. > > As is, powerd may be running, but it's doing so highly inefficiently; > refer to Stefan, Adrian and Kevin's responses for details. > > cheers, Ian It's an Intel Atom running amd64 version of FreeBSD stable/10: FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1 r283292: Sat May 23 01:08:03 EEST 2015 r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz K8-class CPU) Origin="GenuineIntel" Id=0x106ca Family=0x6 Model=0x1c Stepping=10 Features=0xbfebfbff Features2=0x40e31d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics Powerd was working on 10.1-RELEASE but stopped working after upgrade to 10-STABLE and nothing was changed in BIOS settings. However, reading the other replies to this thread I get the impression that powerd(8) doesn't actually save energy on this platform and I'm better off without it? -Kimmo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CPU frequency doesn't drop below 1200MHz (like it used to)
On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote: > On Sat, May 23, 2015 at 10:00 AM, Ian Smith wrote: > > On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote: > > > On Fri, May 22, 2015 at 8:19 PM, Ian Smith wrote: > > > > On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote: > > > > > On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko > > wrote: > > [..] > > > >> Try changing the options in /boot/device.hints > > > >> hint.acpi_throttle.0.disabled="0" > > > >> hint.p4tcc.0.disabled="0" > > > > > > > > > Thanks, those also fixed powerd(8) for me that stopped working > > after > > > > > upgrading to stable/10 from releng/10.1. Why are those setting > > > > > suddenly needed now? > > [..] > > > > Can you say exactly in what way powerd stopped working then? > > > > > > Powerd(8) complained (excerpt from dmesg -a): > > > > > > Starting powerd. > > > powerd: no cpufreq(4) support -- aborting: No such file or directory > > > /etc/rc: WARNING: failed to start powerd > > > > > > Putting those two settings in loader.conf and rebooting fixed the > > > problem and powerd started working again apparently because cpufreq(4) > > > device was available again. > > > > Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus > > powerd - work for you, then it seems likely that you do not have EST > > enabled in your BIOS. Or at least, we've seen another instance where > > that was the case, which was fixed by enabling EST (or however your > > particular BIOS refers to it .. AMD for example use different terms). > > > > What CPU is this? In what machine? > > > > If EST (ono) IS enabled in your BIOS, this needs further investigation. > > > > As is, powerd may be running, but it's doing so highly inefficiently; > > refer to Stefan, Adrian and Kevin's responses for details. > It's an Intel Atom running amd64 version of FreeBSD stable/10: > > FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1 > r283292: Sat May 23 01:08:03 EEST 2015 > r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 > > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x106ca Family=0x6 Model=0x1c Stepping=10 > > Features=0xbfebfbff > Features2=0x40e31d > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > > Powerd was working on 10.1-RELEASE but stopped working after upgrade > to 10-STABLE and nothing was changed in BIOS settings. Which would be consistent with EST not being enabled in your BIOS; with no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or acpi_throttle and uses that, as a last resort really; with those also disabled, no cpufreq, so no powerd. Have you checked BIOS settings to confirm that you do have SpeedStep (however termed) properly enabled? Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels` > However, reading the other replies to this thread I get the impression > that powerd(8) doesn't actually save energy on this platform and I'm > better off without it? No, I don't think that's correct; using deeper C-states is most likely a bigger win, but higher than needed CPU freq will still use extra power, so run hotter. `sysctl dev.cpu` will also reveal your C-state usage. Reason I'm pursuing this is that this change shouldn't hurt, but it will flush out those cases where people were only getting cpufreq due to use of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS; I suspect yours may be one such case :) If not, there's a bug to fix. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CPU frequency doesn't drop below 1200MHz (like it used to)
On Sat, May 23, 2015 at 5:15 PM, Ian Smith wrote: > On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote: > > On Sat, May 23, 2015 at 10:00 AM, Ian Smith wrote: > > > On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote: > > > > On Fri, May 22, 2015 at 8:19 PM, Ian Smith > wrote: > > > > > On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote: > > > > > > On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko > wrote: > > > [..] > > > > >> Try changing the options in /boot/device.hints > > > > >> hint.acpi_throttle.0.disabled="0" > > > > >> hint.p4tcc.0.disabled="0" > > > > > > > > > > > Thanks, those also fixed powerd(8) for me that stopped working > after > > > > > > upgrading to stable/10 from releng/10.1. Why are those setting > > > > > > suddenly needed now? > > > [..] > > > > > Can you say exactly in what way powerd stopped working then? > > > > > > > > Powerd(8) complained (excerpt from dmesg -a): > > > > > > > > Starting powerd. > > > > powerd: no cpufreq(4) support -- aborting: No such file or directory > > > > /etc/rc: WARNING: failed to start powerd > > > > > > > > Putting those two settings in loader.conf and rebooting fixed the > > > > problem and powerd started working again apparently because cpufreq(4) > > > > device was available again. > > > > > > Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus > > > powerd - work for you, then it seems likely that you do not have EST > > > enabled in your BIOS. Or at least, we've seen another instance where > > > that was the case, which was fixed by enabling EST (or however your > > > particular BIOS refers to it .. AMD for example use different terms). > > > > > > What CPU is this? In what machine? > > > > > > If EST (ono) IS enabled in your BIOS, this needs further investigation. > > > > > > As is, powerd may be running, but it's doing so highly inefficiently; > > > refer to Stefan, Adrian and Kevin's responses for details. > > > It's an Intel Atom running amd64 version of FreeBSD stable/10: > > > > FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1 > > r283292: Sat May 23 01:08:03 EEST 2015 > > r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 > > > > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x106ca Family=0x6 Model=0x1c Stepping=10 > > > Features=0xbfebfbff > > Features2=0x40e31d > > AMD Features=0x20100800 > > AMD Features2=0x1 > > TSC: P-state invariant, performance statistics > > > > Powerd was working on 10.1-RELEASE but stopped working after upgrade > > to 10-STABLE and nothing was changed in BIOS settings. > > Which would be consistent with EST not being enabled in your BIOS; with > no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or > acpi_throttle and uses that, as a last resort really; with those also > disabled, no cpufreq, so no powerd. Have you checked BIOS settings to > confirm that you do have SpeedStep (however termed) properly enabled? > > Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels` > > > However, reading the other replies to this thread I get the impression > > that powerd(8) doesn't actually save energy on this platform and I'm > > better off without it? > > No, I don't think that's correct; using deeper C-states is most likely a > bigger win, but higher than needed CPU freq will still use extra power, > so run hotter. `sysctl dev.cpu` will also reveal your C-state usage. > > Reason I'm pursuing this is that this change shouldn't hurt, but it will > flush out those cases where people were only getting cpufreq due to use > of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS; > I suspect yours may be one such case :) If not, there's a bug to fix. > > cheers, Ian Looking deeper into this it appears I don't have speedstep (EST) support in the CPU it being a crappy Atom D510: http://ark.intel.com/products/43098 This the full 'sysctl dev.cpu' output: % sysctl dev.cpu dev.cpu.3.cx_usage: 100.00% last 65712us dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_supported: C1/1/0 dev.cpu.3.%parent: acpi0 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%location: handle=\_PR_.P004 dev.cpu.3.%driver: cpu dev.cpu.3.%desc: ACPI CPU dev.cpu.2.cx_usage: 100.00% last 41518us dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_supported: C1/1/0 dev.cpu.2.%parent: acpi0 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%location: handle=\_PR_.P003 dev.cpu.2.%driver: cpu dev.cpu.2.%desc: ACPI CPU dev.cpu.1.cx_usage: 100.00% last 12706us dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_supported: C1/1/0 dev.cpu.1.%parent: acpi0 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%location: handle=\_PR_.P002 dev.cpu.1.%driver: cpu dev.cpu.1.%desc: ACPI CPU dev.cpu.0.cx_usage: 100.00% last 3132us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/0 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%
Re: CPU frequency doesn't drop below 1200MHz (like it used to)
Hm, no thermal monitoring and no speedstep. Could be dangerous/fun. What's the output of sysctl dev.cpu.0 ? -adrian On 23 May 2015 at 07:40, Kimmo Paasiala wrote: > On Sat, May 23, 2015 at 5:15 PM, Ian Smith wrote: >> On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote: >> > On Sat, May 23, 2015 at 10:00 AM, Ian Smith wrote: >> > > On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote: >> > > > On Fri, May 22, 2015 at 8:19 PM, Ian Smith >> wrote: >> > > > > On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote: >> > > > > > On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko >> wrote: >> > > [..] >> > > > >> Try changing the options in /boot/device.hints >> > > > >> hint.acpi_throttle.0.disabled="0" >> > > > >> hint.p4tcc.0.disabled="0" >> > > > > >> > > > > > Thanks, those also fixed powerd(8) for me that stopped working >> after >> > > > > > upgrading to stable/10 from releng/10.1. Why are those setting >> > > > > > suddenly needed now? >> > > [..] >> > > > > Can you say exactly in what way powerd stopped working then? >> > > > >> > > > Powerd(8) complained (excerpt from dmesg -a): >> > > > >> > > > Starting powerd. >> > > > powerd: no cpufreq(4) support -- aborting: No such file or directory >> > > > /etc/rc: WARNING: failed to start powerd >> > > > >> > > > Putting those two settings in loader.conf and rebooting fixed the >> > > > problem and powerd started working again apparently because >> cpufreq(4) >> > > > device was available again. >> > > >> > > Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus >> > > powerd - work for you, then it seems likely that you do not have EST >> > > enabled in your BIOS. Or at least, we've seen another instance where >> > > that was the case, which was fixed by enabling EST (or however your >> > > particular BIOS refers to it .. AMD for example use different terms). >> > > >> > > What CPU is this? In what machine? >> > > >> > > If EST (ono) IS enabled in your BIOS, this needs further investigation. >> > > >> > > As is, powerd may be running, but it's doing so highly inefficiently; >> > > refer to Stefan, Adrian and Kevin's responses for details. >> >> > It's an Intel Atom running amd64 version of FreeBSD stable/10: >> > >> > FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1 >> > r283292: Sat May 23 01:08:03 EEST 2015 >> > r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 >> > >> > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz K8-class CPU) >> > Origin="GenuineIntel" Id=0x106ca Family=0x6 Model=0x1c Stepping=10 >> > >> Features=0xbfebfbff >> > >> Features2=0x40e31d >> > AMD Features=0x20100800 >> > AMD Features2=0x1 >> > TSC: P-state invariant, performance statistics >> > >> > Powerd was working on 10.1-RELEASE but stopped working after upgrade >> > to 10-STABLE and nothing was changed in BIOS settings. >> >> Which would be consistent with EST not being enabled in your BIOS; with >> no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or >> acpi_throttle and uses that, as a last resort really; with those also >> disabled, no cpufreq, so no powerd. Have you checked BIOS settings to >> confirm that you do have SpeedStep (however termed) properly enabled? >> >> Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels` >> >> > However, reading the other replies to this thread I get the impression >> > that powerd(8) doesn't actually save energy on this platform and I'm >> > better off without it? >> >> No, I don't think that's correct; using deeper C-states is most likely a >> bigger win, but higher than needed CPU freq will still use extra power, >> so run hotter. `sysctl dev.cpu` will also reveal your C-state usage. >> >> Reason I'm pursuing this is that this change shouldn't hurt, but it will >> flush out those cases where people were only getting cpufreq due to use >> of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS; >> I suspect yours may be one such case :) If not, there's a bug to fix. >> >> cheers, Ian > > Looking deeper into this it appears I don't have speedstep (EST) > support in the CPU it being a crappy Atom D510: > > http://ark.intel.com/products/43098 > > This the full 'sysctl dev.cpu' output: > > % sysctl dev.cpu > dev.cpu.3.cx_usage: 100.00% last 65712us > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_supported: C1/1/0 > dev.cpu.3.%parent: acpi0 > dev.cpu.3.%pnpinfo: _HID=none _UID=0 > dev.cpu.3.%location: handle=\_PR_.P004 > dev.cpu.3.%driver: cpu > dev.cpu.3.%desc: ACPI CPU > dev.cpu.2.cx_usage: 100.00% last 41518us > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_supported: C1/1/0 > dev.cpu.2.%parent: acpi0 > dev.cpu.2.%pnpinfo: _HID=none _UID=0 > dev.cpu.2.%location: handle=\_PR_.P003 > dev.cpu.2.%driver: cpu > dev.cpu.2.%desc: ACPI CPU > dev.cpu.1.cx_usage: 100.00% last 12706us > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_supported: C1/1/0 >
Re: CPU frequency doesn't drop below 1200MHz (like it used to)
On Sat, 23 May 2015 17:40:26 +0300, Kimmo Paasiala wrote:
> On Sat, May 23, 2015 at 5:15 PM, Ian Smith wrote:
[..]
> > > It's an Intel Atom running amd64 version of FreeBSD stable/10:
> > >
> > > FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
> > > r283292: Sat May 23 01:08:03 EEST 2015
> > > r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64
> > >
> > > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz K8-class CPU)
> > > Origin="GenuineIntel" Id=0x106ca Family=0x6 Model=0x1c Stepping=10
> > >
> > Features=0xbfebfbff
> > >
> > Features2=0x40e31d
> > > AMD Features=0x20100800
> > > AMD Features2=0x1
> > > TSC: P-state invariant, performance statistics
> > >
> > > Powerd was working on 10.1-RELEASE but stopped working after upgrade
> > > to 10-STABLE and nothing was changed in BIOS settings.
[..]
> > > However, reading the other replies to this thread I get the impression
> > > that powerd(8) doesn't actually save energy on this platform and I'm
> > > better off without it?
> >
> > No, I don't think that's correct; using deeper C-states is most likely a
> > bigger win, but higher than needed CPU freq will still use extra power,
> > so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.
> >
> > Reason I'm pursuing this is that this change shouldn't hurt, but it will
> > flush out those cases where people were only getting cpufreq due to use
> > of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS;
> > I suspect yours may be one such case :) If not, there's a bug to fix.
Seems _I've_ got a bug to fix; I need to stop assuming all modern Intel
CPUs are going to make SpeedStep and/or deeper C-states available :(
> Looking deeper into this it appears I don't have speedstep (EST)
> support in the CPU it being a crappy Atom D510:
>
> http://ark.intel.com/products/43098
Indeed. It is rated at only 13W TDP, so relatively low power anyway.
> This the full 'sysctl dev.cpu' output:
>
> % sysctl dev.cpu
> dev.cpu.3.cx_usage: 100.00% last 65712us
> dev.cpu.3.cx_lowest: C1
> dev.cpu.3.cx_supported: C1/1/0
[..]
> dev.cpu.0.cx_usage: 100.00% last 3132us
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_supported: C1/1/0
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%location: handle=\_PR_.P001
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%desc: ACPI CPU
> dev.cpu.%parent:
It doesn't even provide dev.cpu.0.freq, and has no deeper C-states
('Idle States' on that page) available, so it looks like you may as well
not bother running powerd. Others maybe can offer better suggestions.
> So I should keep those two hints in loader.conf to use p4tcc I guess?
If this is a desktop I'd just let it run flat out, ie disable p4tcc and
acpi_throttle, have no cpufreq and forget powerd.
If it's a laptop and power consumption on battery matters to you, you
could see if p4tcc's lower frequencies actually save any power much, by
running 'powerd -v' in a terminal while testing with different loads, or
if your 'acpiconf -i0' shows discharging rates in mA or mW, or both.
Sorry again for my poor assumption, and thanks for the data point!
cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CPU frequency doesn't drop below 1200MHz (like it used to)
On Sat, May 23, 2015 at 6:57 PM, Ian Smith wrote:
> On Sat, 23 May 2015 17:40:26 +0300, Kimmo Paasiala wrote:
> > On Sat, May 23, 2015 at 5:15 PM, Ian Smith wrote:
> [..]
> > > > It's an Intel Atom running amd64 version of FreeBSD stable/10:
> > > >
> > > > FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
> > > > r283292: Sat May 23 01:08:03 EEST 2015
> > > > r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64
> > > >
> > > > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz K8-class CPU)
> > > > Origin="GenuineIntel" Id=0x106ca Family=0x6 Model=0x1c
> Stepping=10
> > > >
> Features=0xbfebfbff
> > > >
> Features2=0x40e31d
> > > > AMD Features=0x20100800
> > > > AMD Features2=0x1
> > > > TSC: P-state invariant, performance statistics
> > > >
> > > > Powerd was working on 10.1-RELEASE but stopped working after upgrade
> > > > to 10-STABLE and nothing was changed in BIOS settings.
> [..]
> > > > However, reading the other replies to this thread I get the impression
> > > > that powerd(8) doesn't actually save energy on this platform and I'm
> > > > better off without it?
> > >
> > > No, I don't think that's correct; using deeper C-states is most likely a
> > > bigger win, but higher than needed CPU freq will still use extra power,
> > > so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.
> > >
> > > Reason I'm pursuing this is that this change shouldn't hurt, but it will
> > > flush out those cases where people were only getting cpufreq due to use
> > > of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS;
> > > I suspect yours may be one such case :) If not, there's a bug to fix.
>
> Seems _I've_ got a bug to fix; I need to stop assuming all modern Intel
> CPUs are going to make SpeedStep and/or deeper C-states available :(
>
> > Looking deeper into this it appears I don't have speedstep (EST)
> > support in the CPU it being a crappy Atom D510:
> >
> > http://ark.intel.com/products/43098
>
> Indeed. It is rated at only 13W TDP, so relatively low power anyway.
>
> > This the full 'sysctl dev.cpu' output:
> >
> > % sysctl dev.cpu
>
> > dev.cpu.3.cx_usage: 100.00% last 65712us
> > dev.cpu.3.cx_lowest: C1
> > dev.cpu.3.cx_supported: C1/1/0
> [..]
> > dev.cpu.0.cx_usage: 100.00% last 3132us
> > dev.cpu.0.cx_lowest: C1
> > dev.cpu.0.cx_supported: C1/1/0
> > dev.cpu.0.%parent: acpi0
> > dev.cpu.0.%pnpinfo: _HID=none _UID=0
> > dev.cpu.0.%location: handle=\_PR_.P001
> > dev.cpu.0.%driver: cpu
> > dev.cpu.0.%desc: ACPI CPU
> > dev.cpu.%parent:
>
> It doesn't even provide dev.cpu.0.freq, and has no deeper C-states
> ('Idle States' on that page) available, so it looks like you may as well
> not bother running powerd. Others maybe can offer better suggestions.
>
> > So I should keep those two hints in loader.conf to use p4tcc I guess?
>
> If this is a desktop I'd just let it run flat out, ie disable p4tcc and
> acpi_throttle, have no cpufreq and forget powerd.
>
> If it's a laptop and power consumption on battery matters to you, you
> could see if p4tcc's lower frequencies actually save any power much, by
> running 'powerd -v' in a terminal while testing with different loads, or
> if your 'acpiconf -i0' shows discharging rates in mA or mW, or both.
>
> Sorry again for my poor assumption, and thanks for the data point!
>
> cheers, Ian
It's a firewall/router with some minimal services like nginx running.
I'll just leave it like it's now without any frequency control.
Thanks,
-Kimmo
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: L2ARC degraded. Checksum errors, I/O errors
Once again, do we know if this https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 has been committed yet? -- George Kontostanos --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CPU frequency doesn't drop below 1200MHz (like it used to)
Frequency control may not be relevant on that platform. Try installing the intel-pcm package; then # kldload cpuctl # pcm.x 1 Then paste some of that in here. Let's see if the CPU is idling some other way. -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Status of NFS4.1 FS_RECLAIM in FreeBSD 10.1?
> On May 21, 2015, at 8:19 AM, Rick Macklem wrote: > > Well, if you are just doing an NFSv4.1 mount, you could capture > packets during the failed mount attaempt with tcpdump and then > email me the raw packet capture, I can take a look at it. > (tcpdump doesn't handle nfs packets well, but wireshark will accept > a raw packet capture) Something like: > # tcpdump -s 0 -w .pcap host > should work. > > When I read RFC-5661 around page #567, it seems clear that the > client should use RECLAIM_COMPLETE with the fs arg false after > acquiring a noew clientid, which is what a fresh mount would normally be. > (If the packet capture shows an EXCHANGEID followed by a RECLAIM_COMPLETE > with the fs arg true, I think ESXi is broken, but I can send you a patch > that will just ignore the "true", so it works.) > I think the "true" case is only used when a file system has been "moved" > by a server cluster, indicated to the client via a NFS4ERR_MOVED error > when it is accessed at the old server, but the working in RFC-5661 isn't > very clear. > > rick Thank you kindly. I am travelling at the moment; but as soon as I can, I will get that to you. Much appreciated, Mahmoud ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CPU frequency doesn't drop below 1200MHz (like it used to)
On Sat, May 23, 2015 at 10:41 PM, Adrian Chadd wrote: > Frequency control may not be relevant on that platform. > > Try installing the intel-pcm package; then > > # kldload cpuctl > # pcm.x 1 > > Then paste some of that in here. Let's see if the CPU is idling some other > way. > > > > -adrian Five iterations one every second: Script started on Sun May 24 00:07:18 2015 command: sudo pcm.x 1 -i=5 Intel(r) Performance Counter Monitor V2.8 (2014-12-18 12:52:39 +0100 ID=ba39a89) Copyright (c) 2009-2014 Intel Corporation Number of physical cores: 1 Number of logical cores: 4 Number of online logical cores: 4 Threads (logical cores) per physical core: 4 Num sockets: 1 Physical cores per socket: 1 Core PMU (perfmon) version: 3 Number of core PMU generic (programmable) counters: 2 Width of generic (programmable) counters: 40 bits Number of core PMU fixed counters: 3 Width of fixed counters: 40 bits Nominal core frequency: 166000 Hz Delay: 1 Detected Intel(R) Atom(TM) CPU D510 @ 1.66GHz "Intel(r) microarchitecture codename Atom(tm)" EXEC : instructions per nominal CPU cycle IPC : instructions per CPU cycle FREQ : relation to nominal CPU frequency='unhalted clock ticks'/'invariant timer ticks' (includes Intel Turbo Boost) L2MISS: L2 cache misses L2HIT : L2 cache hit ratio (0.00-1.00) TEMP : Temperature reading in 1 degree Celsius relative to the TjMax temperature (thermal headroom): 0 corresponds to the max temperature Core (SKT) | EXEC | IPC | FREQ | L2MISS | L2HIT | TEMP 00 0.00 0.19 0.00 5513 0.85 89 10 0.00 0.37 0.00 2676 0.84 89 20 0.00 0.39 0.01 21 K0.83 N/A 30 0.00 0.28 0.00 4731 0.64 N/A - TOTAL * 0.00 0.33 0.00 34 K0.82 N/A Instructions retired: K ; Active cycles: 20 M ; Time (TSC): 1765 Mticks ; C0 (active,non-halted) core residency: 0.28 % C1 core residency: 99.72 %; C2 package residency: 0.00 %; C4 package residency: 0.00 %; C6 package residency: 0.00 %; PHYSICAL CORE IPC : 1.33 => corresponds to 66.42 % utilization for cores in active state Instructions per nominal CPU cycle: 0.00 => corresponds to 0.19 % core utilization over time interval -- EXEC : instructions per nominal CPU cycle IPC : instructions per CPU cycle FREQ : relation to nominal CPU frequency='unhalted clock ticks'/'invariant timer ticks' (includes Intel Turbo Boost) L2MISS: L2 cache misses L2HIT : L2 cache hit ratio (0.00-1.00) TEMP : Temperature reading in 1 degree Celsius relative to the TjMax temperature (thermal headroom): 0 corresponds to the max temperature Core (SKT) | EXEC | IPC | FREQ | L2MISS | L2HIT | TEMP 00 0.00 0.19 0.00 6296 0.82 89 10 0.00 0.35 0.00 12 K0.81 89 20 0.00 0.44 0.00 6378 0.84 N/A 30 0.00 0.24 0.00 3846 0.86 N/A - TOTAL * 0.00 0.34 0.00 29 K0.83 N/A Instructions retired: 6646 K ; Active cycles: 19 M ; Time (TSC): 1766 Mticks ; C0 (active,non-halted) core residency: 0.28 % C1 core residency: 99.72 %; C2 package residency: 0.00 %; C4 package residency: 0.00 %; C6 package residency: 0.00 %; PHYSICAL CORE IPC : 1.34 => corresponds to 67.19 % utilization for cores in active state Instructions per nominal CPU cycle: 0.00 => corresponds to 0.19 % core utilization over time interval -- EXEC : instructions per nominal CPU cycle IPC : instructions per CPU cycle FREQ : relation to nominal CPU frequency='unhalted clock ticks'/'invariant timer ticks' (includes Intel Turbo Boost) L2MISS: L2 cache misses L2HIT : L2 cache hit ratio (0.00-1.00) TEMP : Temperature reading in 1 degree Celsius relative to the TjMax temperature (thermal headroom): 0 corresponds to the max temperature Core (SKT) | EXEC | IPC | FREQ | L2MISS | L2HIT | TEMP 00 0.00 0.25 0.00 12 K0.74 89 10 0.00 0.42 0.00 3166 0.94 89 20 0.00 0.19 0.00 4869 0.68 94 30 0.00 0.36 0.00 13 K0.81 94 - TOTAL * 0.00 0.34 0.00 33 K0.82 N/A Instructions retired: 8041 K ; Active cycles: 23 M ; Time (TSC): 1755 Mticks ; C0 (active,non-halted) core residency: 0.34 % C1 core residency: 99.66 %; C2 package residency: 0.00 %; C4 package
