powerd is doing nothing?
Evren Yurtesen
I have boxes with 6.2-x86 to 7.0-amd64 with CPUs from AMD and Intel ranging
between Athlon64, Pentium4, Xeon processors.
OK I have setup powerd and when I run powerd I see (for example):
idle time > 90%, decreasing clock speed from 2978 MHz to 2605 MHz
idle time > 90%, decreasing clock speed from 2605 MHz to 2233 MHz
idle time > 90%, decreasing clock speed from 2233 MHz to 1861 MHz
idle time > 90%, decreasing clock speed from 1861 MHz to 1489 MHz
idle time > 90%, decreasing clock speed from 1489 MHz to 1116 MHz
idle time > 90%, decreasing clock speed from 1116 MHz to 744 MHz
idle time > 90%, decreasing clock speed from 744 MHz to 372 MHz
and sysctl's seem to be in order:
dev.cpu.0.freq: 372
dev.cpu.0.freq_levels: 2978/-1 2605/-1 2233/-1 1861/-1 1489/-1 1116/-1 744/-1 372/-1
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
However, I downloaded acpi_ppc from
http://www.spa.is.uec.ac.jp/~nfukuda/software/ and there comes a program called
chkfreq with it which measures the cpu time. It always shows the maximum speed.
For example 2992751205 for 3ghz P4 (from the above examples) regardless of what
freq is set.
OK lets say the chkfreq is faulty, but I tested this on another machine with 6.2
box with:
CPU: AMD Athlon(tm) 64 Processor 3500+ (2202.83-MHz 686-class CPU)
and acpi_ppc says:
cpu0: Px state: P0, 2200MHz, 89000mW, 100us, 7us
cpu0: Px state: P1, 2000MHz, 69000mW, 100us, 7us
cpu0: Px state: P2, 1800MHz, 50000mW, 100us, 7us
cpu0: Px state: P3, 1000MHz, 22000mW, 100us, 7us
cpu0: Px method: AMD K8 Cool'n'Quiet
and when at 1000mhz chkfreq shows 1001297861 when I unload acpi_ppc it shows
2202845489.
Then I load cpufreq and I see:
powernow0: <Cool`n'Quiet K8> on cpu0
and run powerd
dev.cpu.0.freq: 1000
dev.cpu.0.freq_levels: 2200/89000 2000/69000 1800/50000 1000/22000
dev.powernow.0.freq_settings: 2200/89000 2000/69000 1800/50000 1000/22000
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
but when I run chkfreq I get 2202846202 (I checked with -v, powerd does not
increase speed while testing)
I tested powerd on several machines with p4, athlon64, xeon processors and it
seems to work in none of the machines properly.
Does anybody know how any way to check for sure if powerd is really working or not?
Thanks,
Evren
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
Evren Yurtesen
>
> The problem is not powerd but cpufreq. While cpufreq appears to work
> well on my Athlon X2, it has never worked on any of my Core2Duo or
> Core-based Xeon servers.
>
> This is a great shame as these newer Intel chips have the capability to
> clock up and down very quickly and seamlessly.
>
> Who can fix the cpufreq driver? I think it simply hasn't been updated
> with the latest data from Intel.
Yes I can see that powerd is trying to change the frequency so agreed, cpufreq
is broken.
When you say that it doesnt work, does it give an error or? In my case it doesnt
give any errors just says it set it but I see that nothing is set.
Did you try acpi_ppc? http://www.spa.is.uec.ac.jp/~nfukuda/software/
Andrew Snow
> When you say that it doesnt work, does it give an error or? In my case
> it doesnt give any errors just says it set it but I see that nothing is
> set.
Here's one box:
CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 61a49200600091a
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
Here's another one:
CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 720072006000720
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
SYSCTLs On the first one:
dev.cpu.0.freq: 2786
dev.cpu.0.freq_levels: 2786/-1 2437/-1 2089/-1 1741/-1 1393/-1 1044/-1
696/-1 348/-1
Attempting to change dev.cpu.0.freq has no effect and says:
sysctl: dev.cpu.0.freq: Invalid argument
Evren Yurtesen
In one of the boxes I have there is an option in the bios where I can enable
Intel Enhanced SpeedStep Technology. If I enable this to disabled in the bios
then I get the same results as you are seeing. If I enable this in the bios then
I get no errors but the processor speed doesnt change according to chkfreq from
acpi_ppc http://www.spa.is.uec.ac.jp/~nfukuda/software/
Did you check the bios for this option?
Another thing is that when I enable it from bios the cpufreq finds the processor
to be 1500mhz (3000mhz in reality).
You said you have an Athlon X2 box. Did you download
http://www.spa.is.uec.ac.jp/~nfukuda/software/ and tried the chkfreq program
which comes out with it to see if powerd is actually working? Because all I know
is that you might be thinking that it is working but it might not be working at
all. (I think acpi_ppc doesnt support dual core processors but chkfreq should
give reliable results)
Thanks,
Evren
Roland Smith
> Evren Yurtesen wrote:
>
> > When you say that it doesnt work, does it give an error or? In my case
> > it doesnt give any errors just says it set it but I see that nothing is
> > set.
>
> Here's one box:
>
> CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz
> cpu0: <ACPI CPU> on acpi0
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 61a49200600091a
> device_attach: est0 attach returned 6
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
>
>
> Here's another one:
> CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz
> cpu0: <ACPI CPU> on acpi0
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 720072006000720
> device_attach: est0 attach returned 6
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
issue for me.
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
Evren Yurtesen
> On Thu, Jun 05, 2008 at 08:33:24AM +1000, Andrew Snow wrote:
>> Here's another one:
>> CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz
>> cpu0: <ACPI CPU> on acpi0
>> est0: <Enhanced SpeedStep Frequency Control> on cpu0
>> est: CPU supports Enhanced Speedstep, but is not recognized.
>> est: cpu_vendor GenuineIntel, msr 720072006000720
>> device_attach: est0 attach returned 6
>> p4tcc0: <CPU Frequency Thermal Control> on cpu0
>
> I had this on a new core2 quad. Updating to a recent 7-STABLE fixed the
> issue for me.
Did any of you tried chkfreq which comes with acpi_ppc
http://www.spa.is.uec.ac.jp/~nfukuda/software/ to check if the cpu frequency is
actually changing?
Thanks,
Evren
John Baldwin
> Evren Yurtesen wrote:
>
> > When you say that it doesnt work, does it give an error or? In my case
> > it doesnt give any errors just says it set it but I see that nothing is
> > set.
>
> Here's one box:
>
> CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz
> cpu0: <ACPI CPU> on acpi0
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 61a49200600091a
> device_attach: est0 attach returned 6
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
>
>
> Here's another one:
> CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz
> cpu0: <ACPI CPU> on acpi0
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 720072006000720
> device_attach: est0 attach returned 6
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
You can try http://www.FreeBSD.org/~jhb/patches/est_msr.patch. It won't give
you the full range of speeds for you CPU, but it should give you the high and
low values that we can guess from the upper 32-bits of the MSR.
--
John Baldwin
John Baldwin
> Roland Smith wrote:
> > On Thu, Jun 05, 2008 at 08:33:24AM +1000, Andrew Snow wrote:
> >> Here's another one:
> >> CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz
> >> cpu0: <ACPI CPU> on acpi0
> >> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> >> est: CPU supports Enhanced Speedstep, but is not recognized.
> >> est: cpu_vendor GenuineIntel, msr 720072006000720
> >> device_attach: est0 attach returned 6
> >> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> >
> > I had this on a new core2 quad. Updating to a recent 7-STABLE fixed the
> > issue for me.
>
> Did any of you tried chkfreq which comes with acpi_ppc
> http://www.spa.is.uec.ac.jp/~nfukuda/software/ to check if the cpu frequency
is
> actually changing?
chkfreq checks the frequency by reading the TSC and comparing it across a
sleep. However, newer CPUs actually fix the TSC to increment at a constant
rate (so at lower CPU speeds 1 CPU tick may actuall be N TSC ticks) to make
it easier to use the TSC for timekeeping. Thus, chkfreq will think that
newer CPUs are running at the maximum speed when they aren't. This is
actually a feature of newer CPUs.
Try turning off powerd and using 'openssl speed rsa' at different frequencies
to check for real frequency changes.
--
John Baldwin
Evren Yurtesen
The patch is causing errors in kernel compilation in FreeBSD 7-Stable.
inter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse
-mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables
-ffreestanding -Werror /usr/src/sys/kern/imgact_elf32.c
cc -c -O -pipe -march=nocona -std=c99 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100
--param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387
-mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -Werror
/usr/src/sys/i386/cpufreq/powernow.c
cc -c -O -pipe -march=nocona -std=c99 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100
--param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387
-mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -Werror
/usr/src/sys/i386/cpufreq/est.c
/usr/src/sys/i386/cpufreq/est.c: In function 'bus_speed_ok':
/usr/src/sys/i386/cpufreq/est.c:1206: error: invalid storage class for function
'est_msr_info'
cc1: warnings being treated as errors
/usr/src/sys/i386/cpufreq/est.c:1206: warning: no previous prototype for
'est_msr_info'
/usr/src/sys/i386/cpufreq/est.c:1270: error: invalid storage class for function
'est_get_id16'
/usr/src/sys/i386/cpufreq/est.c:1270: warning: no previous prototype for
'est_get_id16'
/usr/src/sys/i386/cpufreq/est.c:1276: error: invalid storage class for function
'est_set_id16'
/usr/src/sys/i386/cpufreq/est.c:1276: warning: no previous prototype for
'est_set_id16'
/usr/src/sys/i386/cpufreq/est.c:1303: error: invalid storage class for function
'est_get_current'
/usr/src/sys/i386/cpufreq/est.c:1303: warning: no previous prototype for
'est_get_current'
/usr/src/sys/i386/cpufreq/est.c:1326: error: invalid storage class for function
'est_settings'
/usr/src/sys/i386/cpufreq/est.c:1326: warning: no previous prototype for
'est_settings'
/usr/src/sys/i386/cpufreq/est.c:1350: error: invalid storage class for function
'est_set'
/usr/src/sys/i386/cpufreq/est.c:1350: warning: no previous prototype for 'est_set'
/usr/src/sys/i386/cpufreq/est.c:1371: error: invalid storage class for function
'est_get'
/usr/src/sys/i386/cpufreq/est.c:1371: warning: no previous prototype for 'est_get'
/usr/src/sys/i386/cpufreq/est.c:1390: error: invalid storage class for function
'est_type'
/usr/src/sys/i386/cpufreq/est.c:1390: warning: no previous prototype for 'est_type'
/usr/src/sys/i386/cpufreq/est.c:1397: error: expected declaration or statement
at end of input
*** Error code 1
Stop in /usr/obj/usr/src/sys/MAIL.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
mail:/usr/src#
By the way, there is another thing I am wondering about. If I enable HTT and
Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see:
cpu0: <ACPI CPU> on acpi0
acpi_perf0: <ACPI CPU Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr f2700000f27
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750
750/8125 600/6500 450/4875 300/3250 150/1625
dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
and it does not allow me to set the freq. of the cpu.
If I disable HTT then I see:
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est0: Setting 1500 MHz
p4tcc0: <CPU Frequency Thermal Control> on cpu0
dev.cpu.0.freq: 1500
dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750
750/8125 600/6500 450/4875 300/3250 150/1625
dev.est.0.freq_settings: 1500/27000 1200/13000
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
I see the vcore goes to 2.32 when I set the speed to 150 according to mbmon, and
when I set the speed to 1500 vcore goes to 2.51
Independent of HTT being active or not, when I enable Intel Enhanced SpeedStep
from the bios I start seeing calcru messages:
calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero)
calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon)
calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon)
calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: task
queue)
calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event)
calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net)
calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init)
calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init)
calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)
Another weird thing is that if I keep HTT enable but disable Intel Enhanced
SpeedStep then I see:
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr f2700000f27
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr f2700000f27
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
and
dev.cpu.0.freq: 2978
dev.cpu.0.freq_levels: 2978/-1 2605/-1 2233/-1 1861/-1 1489/-1 1116/-1 744/-1 372/-1
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1
Notice the correct frequency and changing dev.cpu.0.freq effects the openssl
speed rsa test so it is working. However when I change the dev.cpu.0.freq I
receive an error (but it changes anyway):
mail:/root#sysctl -w dev.cpu.0.freq=2978
dev.cpu.0.freq: 744
sysctl: dev.cpu.0.freq: Invalid argument
mail:/root#sysctl -w dev.cpu.0.freq=2978
dev.cpu.0.freq: 2978
sysctl: dev.cpu.0.freq: Invalid argument
mail:/root#
and the openssl speed rsa test returns results which are consistent with the
speed set. But, regardless of the speed set, mbmon shows 2.54volts all the time.
When HTT and Intel Enhanced Speedstep is disabled in bios I see:
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr f2700000f27
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
and
dev.cpu.0.freq: 2977
dev.cpu.0.freq_levels: 2977/-1 2604/-1 2232/-1 1860/-1 1488/-1 1116/-1 744/-1 372/-1
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
Also the sysctl changes do not return an error however the vcore voltage still
remains constant according to mbmon.
Is there a reason why HTT is not properly detected by cpufreq and behaved
accordingly?
Thanks,
Evren
Thanks,
Evren
Jeremy Chadwick
> By the way, there is another thing I am wondering about. If I enable HTT
> and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see:
>
> cpu0: <ACPI CPU> on acpi0
> acpi_perf0: <ACPI CPU Frequency Control> on cpu0
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> cpu1: <ACPI CPU> on acpi0
> est1: <Enhanced SpeedStep Frequency Control> on cpu1
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr f2700000f27
> device_attach: est1 attach returned 6
> p4tcc1: <CPU Frequency Thermal Control> on cpu1
>
> dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750
> 750/8125 600/6500 450/4875 300/3250 150/1625
> dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000
> dev.cpufreq.0.%driver: cpufreq
> dev.cpufreq.0.%parent: cpu0
> dev.cpufreq.1.%driver: cpufreq
> dev.cpufreq.1.%parent: cpu1
> dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
> 2500/-1 1250/-1
> dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
> 2500/-1 1250/-1
>
> and it does not allow me to set the freq. of the cpu.
How are you setting the frequency? Are you using powerd? You do not
have to enable SpeedStep in your BIOS to achieve throttling CPU clock
speed. In fact, I would highly recommend leaving EIST/SpeedStep in the
BIOS *disabled*, and let powerd adjust the clock frequency via ACPI.
> I see the vcore goes to 2.32 when I set the speed to 150 according to
> mbmon, and when I set the speed to 1500 vcore goes to 2.51
mbmon is giving you wrong values. There is no way your Vcore on a P4 is
2.32 or 2.51 volts. It's very likely that mbmon doesn't support your
hardware monitoring I/C. What motherboard (exact model) do you have?
> Independent of HTT being active or not, when I enable Intel Enhanced
> SpeedStep from the bios I start seeing calcru messages:
>
> calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero)
> calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon)
> calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon)
> calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6:
> task queue)
> calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event)
> calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net)
> calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init)
> calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init)
> calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)
I've documented this problem quite clearly on my Commonly Reported
Issues wiki page. See "Kernel - EIST incompatibilities":
http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues
The solution is to keep EIST (SpeedStep) disabled in the BIOS. You can
still use powerd to adjust CPU clock frequency via ACPI.
> Another weird thing is that if I keep HTT enable but disable Intel Enhanced
> SpeedStep then I see:
>
> ...
>
> Also the sysctl changes do not return an error however the vcore voltage
> still remains constant according to mbmon.
Again: it's highly unlikely mbmon is returning correct values. mbmon
and healthd both were written with very old hardware (circa late 90s,
very early 2001-2002) in mind. The chips they support are not very
common on consumer motherboards, and are no longer used on server
motherboards.
You might be interested in my bsdhwmon(8) application, but please note
I'm trying to avoid supporting any sort of "consumer" motherboards,
because many of them do not offer SMBus tie-ins, not to mention many
consumer board vendors don't provide any sort of documentation on how to
access said H/W IC functionality:
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Evren Yurtesen
I have tested if it is working or not without using powerd. However you are
right, SpeedStep in bios seem to be adding some ACPI support which looks like
kind of broken.
In either case, I get error when I have HTT as powerd (powerd -v) is only able
to change 1 CPUs speed (obviously). Perhaps this can be fixed in future hopefully.
In the bios, there is also Enhanced C1 support which seems to be reducing the
vcore voltage at the same clock speed. (is this normal even?)
>> I see the vcore goes to 2.32 when I set the speed to 150 according to
>> mbmon, and when I set the speed to 1500 vcore goes to 2.51
>
> mbmon is giving you wrong values. There is no way your Vcore on a P4 is
> 2.32 or 2.51 volts. It's very likely that mbmon doesn't support your
> hardware monitoring I/C. What motherboard (exact model) do you have?
I thought about that actually but at this moment the importance is that it is
changing only under certain conditions, there is probably some mistake in mbmon
which skews the results.
This is the motherboard (information from the datacenter):
http://www.supermicro.com/products/motherboard/PD/E7230/PDSML-LN2.cfm
Although kenv | grep smbios show PDSBM can this be or the datacenter is wrong?
I just went to bios and says 1.264v so I guess it is safe to assume that mbmon
was showing double.
>> Independent of HTT being active or not, when I enable Intel Enhanced
>> SpeedStep from the bios I start seeing calcru messages:
>>
>> calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero)
>> calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon)
>> calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon)
>> calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6:
>> task queue)
>> calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event)
>> calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net)
>> calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init)
>> calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init)
>> calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)
>
> I've documented this problem quite clearly on my Commonly Reported
> Issues wiki page. See "Kernel - EIST incompatibilities":
>
> http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues
>
> The solution is to keep EIST (SpeedStep) disabled in the BIOS. You can
> still use powerd to adjust CPU clock frequency via ACPI.
Yes, I have nothing against keeping it closed. :)
>> Another weird thing is that if I keep HTT enable but disable Intel Enhanced
>> SpeedStep then I see:
>>
>> ...
>>
>> Also the sysctl changes do not return an error however the vcore voltage
>> still remains constant according to mbmon.
>
> Again: it's highly unlikely mbmon is returning correct values. mbmon
> and healthd both were written with very old hardware (circa late 90s,
> very early 2001-2002) in mind. The chips they support are not very
> common on consumer motherboards, and are no longer used on server
> motherboards.
>
> You might be interested in my bsdhwmon(8) application, but please note
> I'm trying to avoid supporting any sort of "consumer" motherboards,
> because many of them do not offer SMBus tie-ins, not to mention many
> consumer board vendors don't provide any sort of documentation on how to
> access said H/W IC functionality:
Yes, as a coincidence I found:
http://fixunix.com/freebsd/384760-looking-supermicro-hardware-owners.html
I have 2 other servers with:
http://www.supermicro.com/products/motherboard/Xeon1333/5000V/X7DVL-i.cfm
(eh this one gives "X7DVL" correctly in kenv output also :) )
and I have some Intel products. I can test out bsdhwmon...
I will send you the bios screenshots later to your e-mail. I have to leave now
for a short while.
Thanks,
Evren
Jeremy Chadwick
> I have tested if it is working or not without using powerd. However you are
> right, SpeedStep in bios seem to be adding some ACPI support which looks
> like kind of broken.
>
> In either case, I get error when I have HTT as powerd (powerd -v) is only
> able to change 1 CPUs speed (obviously). Perhaps this can be fixed in
> future hopefully.
I believe you can only adjust the clock frequency of both CPUs/cores on
Intel platforms. At least that's how it is under Windows, and under PC
BIOSes. If you have a CPU that has dual cores, both cores will have
their frequency adjusted. If you have dual physical CPUs that have dual
cores, any frequency adjustment should apply to all CPUs.
> In the bios, there is also Enhanced C1 support which seems to be reducing
> the vcore voltage at the same clock speed. (is this normal even?)
Enhanced C1 support allows the CPU to go into a deeper sleep state
during idle periods. I recommend enabling it, even on server systems.
You can safely enable it on systems using FreeBSD.
You might be interested in the utility for Windows called RMClock, which
provides an incredible amount of low-level information about CPUs and
chipsets. Yes, I know it's for Windows, but if you ever boot Windows,
it's a fantastic utility.
> This is the motherboard (information from the datacenter):
> http://www.supermicro.com/products/motherboard/PD/E7230/PDSML-LN2.cfm
> Although kenv | grep smbios show PDSBM can this be or the datacenter is wrong?
I can add support for this motherboard to bsdhwmon(8), assuming you can
get me a few pieces of information. (Edit: Actually, seems you've
already contacted me with this information! Thanks!)
I'll need to contact Supermicro to get Winbond interface details,
however. That can take a couple weeks.
> I just went to bios and says 1.264v so I guess it is safe to assume that
> mbmon was showing double.
mbmon is showing you invalid values. The fact that it's a value that
happens to be double in value is pure chance. mbmon is not properly
working with your motherboard. It's that simple. :-)
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
_______________________________________________
Kevin Oberman
> From: Jeremy Chadwick <koi...@FreeBSD.org>
> Sender: owner-free...@freebsd.org
I must strongly recommend against this. EST is MUCH more efficient on
its control of power use than simple throttling. So much so that on my
systems that support EST, I remove cpufreq from the kernel. (In all
cases, throttling means either simple throttling or throttling by using
TCC.)
I did quite a bit of testing on power management a year or so ago and
found that throttling was of value only for controlling CPU temperature.
For real power management, EST works far better as it adjust frequency
(actual clock rate) and CPU voltage while throttling just stops and
starts the clock without changing its actual frequency. (This came as a
surprise to me about 5 years ago when I first discovered it.)
At idle, throttling does exactly nothing. EST reduces voltage on the
CPU and saves power even when idle. At full CPU load, throttling reduces
performance and power consumption equally. EST beats it by a slim
margin.
The big win is at moderate load. Throttling can result is very poor
results for aps like video and music which will place a continuous load
on the system, but only 20-60% (in the case of my test system). It
tended to make the system seem sluggish. EST does a much better job in
this case as it lowers CP voltage and clock rate to maximize performance
while minimizing power.
If your only concern is keeping the system cool, throttling will do the
job, but if you want efficient power utilization, use EST if possible.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Jeremy Chadwick
The reality of the situation is that users cannot use EIST reliably on
FreeBSD. I cannot imagine removing cpufreq would solve the "runtime
went backwards" issue. The EIST problem needs to be fixed. If the
folks who work on it do not have present-day hardware (C2Ds, etc.), I
will be more than happy to purchase them whatever they need.
> I did quite a bit of testing on power management a year or so ago and
> found that throttling was of value only for controlling CPU temperature.
> For real power management, EST works far better as it adjust frequency
> (actual clock rate) and CPU voltage while throttling just stops and
> starts the clock without changing its actual frequency. (This came as a
> surprise to me about 5 years ago when I first discovered it.)
As far as I know, the ACPI frequency toggling does in fact adjust the
CPU clock rate -- because the values in dev.cpu.0.freq_levels are
defined by the ACPI configuration on the machine.
I'd confirm this, but looking at the kernel code doesn't help -- I
cannot find the definition of the CPUFREQ_LEVELS function or macro.
> At idle, throttling does exactly nothing. EST reduces voltage on the
> CPU and saves power even when idle. At full CPU load, throttling reduces
> performance and power consumption equally. EST beats it by a slim
> margin.
I thought the power-saving modes of the CPU (C1E/C2E/C3E/C4E) could be
used *without* enabling EIST. I don't think FreeBSD has kernel or
userland support utilities to enable/disable CPU-level features.
Something like RMClock for Windows would be quite useful. (If you have
the opportunity to run it, do so; you'll see what I mean, re: all the
features being toggleable individually).
> The big win is at moderate load. Throttling can result is very poor
> results for aps like video and music which will place a continuous load
> on the system, but only 20-60% (in the case of my test system). It
> tended to make the system seem sluggish. EST does a much better job in
> this case as it lowers CP voltage and clock rate to maximize performance
> while minimizing power.
>
> If your only concern is keeping the system cool, throttling will do the
> job, but if you want efficient power utilization, use EST if possible.
In the case est does not attach (e.g. no EIST support enabled in
FreeBSD), the throttling method resorts to simply suspending the system,
then yes I completely agree -- EIST is significantly better than that.
Kevin Oberman
It claims to adjust clock speed, but it actually simply "skips"
cycles. The system clocks at its standard rate or that provided by other
power management tools. Since throttling (whether done by the external
throttling or TCC) will provide 8 "frequencies". If SpeedStep, EST, or
PowerNow is available, it will show 8 times the number of "true"
frequencies provided by any of those. (Actually, on my system EST
provides 16 "frequencies" of which 4 are actual changes in the clock
and the others are from 4 voltages it uses. 4**2 = 16.
If you see exactly eight "frequencies" with cpufreq, you have no "true"
frequency adjustment.
> I'd confirm this, but looking at the kernel code doesn't help -- I
> cannot find the definition of the CPUFREQ_LEVELS function or macro.
>
> > At idle, throttling does exactly nothing. EST reduces voltage on the
> > CPU and saves power even when idle. At full CPU load, throttling reduces
> > performance and power consumption equally. EST beats it by a slim
> > margin.
>
> I thought the power-saving modes of the CPU (C1E/C2E/C3E/C4E) could be
> used *without* enabling EIST. I don't think FreeBSD has kernel or
> userland support utilities to enable/disable CPU-level features.
> Something like RMClock for Windows would be quite useful. (If you have
> the opportunity to run it, do so; you'll see what I mean, re: all the
> features being toggleable individually).
Yes, C-states are not tied to EST or any "frequency-like" things. And
they are a really significant factor in power saving. I'll have to look
at RMClock. I am not familiar with it. (I don't normally use Windows,
but I can boot it on my laptop.)
> > The big win is at moderate load. Throttling can result is very poor
> > results for aps like video and music which will place a continuous load
> > on the system, but only 20-60% (in the case of my test system). It
> > tended to make the system seem sluggish. EST does a much better job in
> > this case as it lowers CP voltage and clock rate to maximize performance
> > while minimizing power.
> >
> > If your only concern is keeping the system cool, throttling will do the
> > job, but if you want efficient power utilization, use EST if possible.
>
> In the case est does not attach (e.g. no EIST support enabled in
> FreeBSD), the throttling method resorts to simply suspending the system,
> then yes I completely agree -- EIST is significantly better than that.
If you have no better method than throttling, you have to go with it,
but it's way to primitive to be a really big help.
FWIW, on my ThinkPad (uni-processor), with no cpufreq in the system, I
see:
dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725
It is running EST and P4TCC is explicitly disabled in loader.conf.
Oh, and my testing showed that TCC did a slightly better job than simple
throttling, though they do about the same thing, so the difference is
probably not significant. With the current code, if P4TCC is available,
it will be used in preference to throttling. Both will never be used
together. (That was a good way to lock up your system during the time
both were used.)