2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Voluspa]

I'd gladly (ehum..) redo this mind-numbingly boring test if someone can
point me to a magic software which unleashes some untapped powersaving
feature of the CPU.

_Kernel 2.6.13-rc3 Boot to Death_:

2h48m at 100 HZ
2h48m at 250 HZ
2h47m at 1000 HZ

_"Load"_:

#!/bin/sh
touch time-hz-start
while (true) do
    touch time-hz-end
    sleep 1m
done

_Environment_:

No distro (LFS-ish pure 64 bit), no X, no network, no cronjobs, no
peripherals attached. Screen off by hardware switch, but disk obviously
spinning all the time. powernow_k8 + cpufreq_userspace + powernowd-0.96
= 800 MHz at "idle". Fan(s?) always on unless room temperature falls to
a slightly chilly level.

_Machine_:

Acer Aspire 1520 (1524) WLMi, AMD Athlon 64 3400+ (socket 754 according
to dmidecode-2.6). L1 64K/64K, L2 1024K, 512MB DDR RAM. Manufacturing
date 18 March 2005. Bought 20 May 2005. Battery used to full drain ca 5
times prior to this test (after the initial 3 charge/drains to reach its
full potential). "cat /proc/acpi/battery/BAT0/info":

present:                 yes
design capacity:         4000 mAh
last full capacity:      4000 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 400 mAh
design capacity low:     120 mAh
capacity granularity 1:  280 mAh
capacity granularity 2:  3880 mAh
model number:            Bat 8Cell
serial number:           236
battery type:            Lion
OEM info:                Acer

Mvh
Mats Johannesson
--

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Jesper Juhl]

On 7/21/05, Voluspa <lista1@telia.com> wrote:
> 
> I'd gladly (ehum..) redo this mind-numbingly boring test if someone can
> point me to a magic software which unleashes some untapped powersaving
> feature of the CPU.
> 
> _Kernel 2.6.13-rc3 Boot to Death_:
> 
> 2h48m at 100 HZ
> 2h48m at 250 HZ
> 2h47m at 1000 HZ
> 
> _"Load"_:
> 
> #!/bin/sh
> touch time-hz-start
> while (true) do
>     touch time-hz-end
>     sleep 1m
> done
> 
Ok, so with an idle machine, different HZ makes no noticeable
difference, but I'd suspect things would be different if the machine
was actually doing some work.
Would be more interresting to see how long it lasts with a light load
and with a heavy load.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Voluspa]

On Thu, 21 Jul 2005 20:14:32 +0200 Jesper Juhl wrote:
> On 7/21/05, Voluspa <lista1@telia.com> wrote:
[...]
> > 
> Ok, so with an idle machine, different HZ makes no noticeable
> difference, but I'd suspect things would be different if the machine
> was actually doing some work.

I first thought about loading with a loop of md5sum /somedir, play a
wav, fetch a couple of webpages etc. But since the talk has been that
the powersave would come from CPU sleep between "ticks" (I know, I know,
it's not ticks) not having to wake up so often, I decided against a
load.

> Would be more interresting to see how long it lasts with a light load
> and with a heavy load.

I won't do that unless heavily beaten ;-) The battery charge time is
2h10 minutes...

Mvh
Mats Johannesson
--

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Pavel Machek]

Hi!

> > I'd gladly (ehum..) redo this mind-numbingly boring test if someone can
> > point me to a magic software which unleashes some untapped powersaving
> > feature of the CPU.
> > 
> > _Kernel 2.6.13-rc3 Boot to Death_:
> > 
> > 2h48m at 100 HZ
> > 2h48m at 250 HZ
> > 2h47m at 1000 HZ
> > 
> > _"Load"_:
> > 
> > #!/bin/sh
> > touch time-hz-start
> > while (true) do
> >     touch time-hz-end
> >     sleep 1m
> > done
> > 
> Ok, so with an idle machine, different HZ makes no noticeable
> difference, but I'd suspect things would be different if the machine
> was actually doing some work.
> Would be more interresting to see how long it lasts with a light load
> and with a heavy load.

No, I do not think so. Biggest difference should be on completely idle
machine where ACPI can utilize low power states.

Can you check that C3 is utilized? Unloading usb modules may be
neccessary...

								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Voluspa]

On Fri, 22 Jul 2005 16:48:55 +0200 Pavel Machek wrote:
[...]
.......Jesper Juhl wrote
> > Ok, so with an idle machine, different HZ makes no noticeable
> > difference, but I'd suspect things would be different if the machine
> > was actually doing some work.
> > Would be more interresting to see how long it lasts with a light
> > load and with a heavy load.
> 
> No, I do not think so. Biggest difference should be on completely idle
> machine where ACPI can utilize low power states.
> 
> Can you check that C3 is utilized? Unloading usb modules may be
> neccessary...

I've been reading/checking up on this the last four hours since I
had a nagging suspicion that the CPU indeed didn't enter a sleep
state. With all the abbreviations in the ACPI field (S1, C1, P1 etc)
it killed a fair amount of brain cells, but I'd still call faul on this:

from /var/log/kernel
[powernow-k8 module loads processor module which says]
ACPI: CPU0 (power states: C1[C1])

and catting /proc/acpi/processor/CPU0/power gives
active state: C1
max_cstate: C8
bus master activity: 00000000
states:
   *C1: type[C1] promotion[--] demotion[--] latency[000] usage[02998796]

/sys/module/processor/parameters/max_cstate says 8
/sys/module/processor/parameters/bm_history says 4294967295

So I'm a bit baffled that no C2/C3 turns up. I've done a test-compile
with all of ACPI in kernel instead of as modules, but there was no
difference.

I'll unload the whole USB-module part and boot without loading them, but
will it matter? Please provide more details about how to debug this
(very confusing) field.

Mvh
Mats Johannesson
--

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Pavel Machek]

Hi!

> and catting /proc/acpi/processor/CPU0/power gives
> active state: C1
> max_cstate: C8
> bus master activity: 00000000
> states:
>    *C1: type[C1] promotion[--] demotion[--] latency[000] usage[02998796]
> 
> /sys/module/processor/parameters/max_cstate says 8
> /sys/module/processor/parameters/bm_history says 4294967295
> 
> So I'm a bit baffled that no C2/C3 turns up. I've done a test-compile
> with all of ACPI in kernel instead of as modules, but there was no
> difference.
> 
> I'll unload the whole USB-module part and boot without loading them, but
> will it matter? Please provide more details about how to debug this
> (very confusing) field.

Okay, if you have no C2/C3 like the dump above shows, unloading usb
will not help. It seems like your machine is simply not able to do
reasonable powersaving.
								Pavel

-- 
Boycott Kodak -- for their patent abuse against Java.

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Voluspa]

On Fri, 22 Jul 2005 20:02:36 +0200 Pavel Machek wrote:
> Okay, if you have no C2/C3 like the dump above shows, unloading usb
> will not help. It seems like your machine is simply not able to do
> reasonable powersaving.

Because of the CPU, ACPI implementation or because of kernel acpi
quality, x86_64 kernel quirks or...? It seems crazy that a modern CPU
like this should be so backwards as to not implement sleep states. It
being in a notebook and all. I blame intel kernel hackers ;-)

Mvh
Mats Johannesson
--

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Voluspa]

On Fri, 22 Jul 2005 20:02:36 +0200 Pavel Machek wrote:
> will not help. It seems like your machine is simply not able to do
> reasonable powersaving.

Digging up this patch from last month regarding C2 on a AMD K7 implies
that the whole blame can be put on kernel acpi:

http://marc.theaimsgroup.com/?l=linux-kernel&m=111933745131301&w=2

Mvh
Mats Johannesson
--

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Tony Lindgren]

* Voluspa <lista1@telia.com> [050722 11:46]:
> On Fri, 22 Jul 2005 20:02:36 +0200 Pavel Machek wrote:
> > will not help. It seems like your machine is simply not able to do
> > reasonable powersaving.
> 
> Digging up this patch from last month regarding C2 on a AMD K7 implies
> that the whole blame can be put on kernel acpi:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111933745131301&w=2

AFAIK Linux ACPI expects BIOS to contain all the necessary stuff to enable
C2 and C3. Otherwise they won't get enabled, and you have to create a custom
module like the amd76x_pm is.

There's been some talk on adding a module to enable C2 and C3 states for
various chipsets, but nobody seems to have enough time to do it...

Tony

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Bill Davidsen]

Tony Lindgren wrote:
> * Voluspa <lista1@telia.com> [050722 11:46]:
> 
>>On Fri, 22 Jul 2005 20:02:36 +0200 Pavel Machek wrote:
>>
>>>will not help. It seems like your machine is simply not able to do
>>>reasonable powersaving.
>>
>>Digging up this patch from last month regarding C2 on a AMD K7 implies
>>that the whole blame can be put on kernel acpi:
>>
>>http://marc.theaimsgroup.com/?l=linux-kernel&m=111933745131301&w=2
> 
> 
> AFAIK Linux ACPI expects BIOS to contain all the necessary stuff to enable
> C2 and C3. Otherwise they won't get enabled, and you have to create a custom
> module like the amd76x_pm is.

Does that imply that Windows actually has such non-BIOS code, or just 
knows how to find the BIOS code better, or knows how to do other things, 
or ???
> 
> There's been some talk on adding a module to enable C2 and C3 states for
> various chipsets, but nobody seems to have enough time to do it...

I like your first thought better, "Linux ACPI expects BIOS to contain 
all the necessary stuff" I have a bunch of laptops of various ages, and 
I would expect at least the most recent, an ASUS 16??, using a 
"Centrino" chipset, to be supported. It's one of the top few laptopl 
chipsets, and Windows can suspecd it. Can also not only detect but use 
the 1400x1050 screen, but that's another issue :-(

Is it possible that the code to find these capabilities is not fully 
functional? That seems more likely than the system not having the 
capability. NOTE: "seems" as in experienced guess unsupported by other 
relevant information.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Guillaume Chazarain]

2005/7/21, Voluspa <lista1@telia.com>:
> 
> 2h48m at 100 HZ
> 2h48m at 250 HZ
> 2h47m at 1000 HZ

Now, what would be interesting is to see if the lack of differences
comes from the fact that the processor has enough time to sleep,
not enough time, or simply it does not matter.

That is, is it a best case or a worst case ?

> #!/bin/sh
> touch time-hz-start
> while (true) do
>     touch time-hz-end
>     sleep 1m
> done

Why this ?
Why not simply nothing ?
A computer can be idle for more than 1 minute ;-)

-- 
Guillaume

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Voluspa]

On Thu, 21 Jul 2005 20:49:59 +0200 Guillaume Chazarain wrote:
> 2005/7/21, Voluspa <lista1@telia.com>:
> > 
> > 2h48m at 100 HZ
> > 2h48m at 250 HZ
> > 2h47m at 1000 HZ
> 
> Now, what would be interesting is to see if the lack of differences
> comes from the fact that the processor has enough time to sleep,
> not enough time, or simply it does not matter.
> 
> That is, is it a best case or a worst case ?

Those words swished above my head. I'd need serious hand-holding to
conduct any further (meaningful) tests.

> 
> > #!/bin/sh
> > touch time-hz-start
> > while (true) do
> >     touch time-hz-end
> >     sleep 1m
> > done
> 
> Why this ?
> Why not simply nothing ?
> A computer can be idle for more than 1 minute ;-)

I had other things to do than sit with a stopwatch in my hand staring at
a black screen :-) Also, 1 minute is a resonable comparison level.

Mvh
Mats Johannesson
--

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Vojtech Pavlik]

On Thu, Jul 21, 2005 at 08:04:48PM +0200, Voluspa wrote:
> 
> I'd gladly (ehum..) redo this mind-numbingly boring test if someone can
> point me to a magic software which unleashes some untapped powersaving
> feature of the CPU.
> 
> _Kernel 2.6.13-rc3 Boot to Death_:
> 
> 2h48m at 100 HZ
> 2h48m at 250 HZ
> 2h47m at 1000 HZ

Is USB loaded? It'll do 1000 interrupts per second if it is. I'm not sure if
this still is the case on 2.6.13-rc3, please check your /proc/interrupts
to see the rate at which interrupt counters are increasing.

> Acer Aspire 1520 (1524) WLMi, AMD Athlon 64 3400+ (socket 754 according
> to dmidecode-2.6). L1 64K/64K, L2 1024K, 512MB DDR RAM. Manufacturing
> date 18 March 2005. Bought 20 May 2005. Battery used to full drain ca 5
> times prior to this test (after the initial 3 charge/drains to reach its
> full potential). "cat /proc/acpi/battery/BAT0/info":
 
This almost looks like a regular Athlon 64, not even the mobile version.
I wouldn't expect very big deep sleep capabilities on that one. You can
check the 

	/proc/acpi/processor/CPU1/power

file for the list of C states. A normal Athlon64 will likely have only
C0. Mobile chips can go up to C4, which is really deep sleep.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Voluspa]

On Tue, 26 Jul 2005 15:14:39 +0200 Vojtech Pavlik wrote:
> This almost looks like a regular Athlon 64, not even the mobile
> version. I wouldn't expect very big deep sleep capabilities on that
> one. You can check the 
> 
> 	/proc/acpi/processor/CPU1/power
> 
> file for the list of C states. A normal Athlon64 will likely have only
> C0. Mobile chips can go up to C4, which is really deep sleep.

You've probably already seen that /proc/acpi/processor/CPU1/power lists
C1 only here. Ok, with your input regarding normal CPUs I'm inclined
to believe ACPI is correct in my case. Still, I'll learn/read the code.
Always have had a need to finish those long marches.

Mvh
Mats Johannesson
--

RE: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Brown, Len]

 
>>>Digging up this patch from last month regarding C2
>>>on a AMD K7 implies
>>>that the whole blame can be put on kernel acpi:
>>>
>>>http://marc.theaimsgroup.com/?l=linux-kernel&m=111933745131301&w=2

The current Linus tree includes generic ACPI support
for deep C-states on SMP machines. (deep means higher than C1)

I don't have any problem with people having platform specific
modules to handle platform specific features.  However, if
the system really intends to support SMP ACPI C-states deeper
than C1 and the generic ACPI code doesn't support it,
then it is either a Linux/ACPI bug or a BIOS bug -- file away:-)

I.e. The whole concept of ACPI is that you shoulud _not_ need
a platform specific driver to accomplish this.

cheers,
-Len

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Bill Davidsen]

Brown, Len wrote:
>  
> 
>>>>Digging up this patch from last month regarding C2
>>>>on a AMD K7 implies
>>>>that the whole blame can be put on kernel acpi:
>>>>
>>>>http://marc.theaimsgroup.com/?l=linux-kernel&m=111933745131301&w=2
> 
> 
> The current Linus tree includes generic ACPI support
> for deep C-states on SMP machines. (deep means higher than C1)
> 
> I don't have any problem with people having platform specific
> modules to handle platform specific features.  However, if
> the system really intends to support SMP ACPI C-states deeper
> than C1 and the generic ACPI code doesn't support it,
> then it is either a Linux/ACPI bug or a BIOS bug -- file away:-)
> 
> I.e. The whole concept of ACPI is that you shoulud _not_ need
> a platform specific driver to accomplish this.

Is anyone but me interested in low power states for servers? I have 
several groups of servers which are lightly utilized for at least 12 
hours every day and on weekends. I currently use IDE drives so I can 
spin them down when idle, do logging either to a single drive or over 
the network whichever makes the most sense, and any drop in power use 
saves double, since I pay for the server power and the A/C power as well.

I haven't seen much discussion of this, but in many cases it would 
result in a saving, perhaps fairly large. Some environmental benefit as 
well, of course.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

[Voluspa]

On 2005-07-26 5:23:08 Len Brown wrote:

>than C1 and the generic ACPI code doesn't support it,
>then it is either a Linux/ACPI bug or a BIOS bug -- file away:-)

The issue has made me fume enough to contemplating installing windos for
the first time in some 10 years. But I'll persevere. Will learn
ACPI-speak, read bios- and kernelcode. Then return, have no fear (even
if just to admit that the BIOS is buggy). Speaking of bugs, I was
directed, off-list, to the patch which mends your latest chip-away of
C2/C3 for many systems:

http://marc.theaimsgroup.com/?l=acpi4linux&m=112138186129178&w=2

It did however not fix my K8 system.

>I.e. The whole concept of ACPI is that you shoulud _not_ need
>a platform specific driver to accomplish this.

Indeed. It's supposed to be some kind of neutral non-discrimatory
standard... I suppose.

Mvh
Mats Johannesson
--