Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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=111933745131301=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 ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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=112138186129178=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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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=acpi4linuxm=112138186129178w=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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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-kernelm=111933745131301w=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 ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
>>>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=111933745131301=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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
Tony Lindgren wrote: * Voluspa <[EMAIL PROTECTED]> [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=111933745131301=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 ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
* Voluspa <[EMAIL PROTECTED]> [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=111933745131301=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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
* Voluspa [EMAIL PROTECTED] [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-kernelm=111933745131301w=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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
Tony Lindgren wrote: * Voluspa [EMAIL PROTECTED] [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-kernelm=111933745131301w=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 ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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-kernelm=111933745131301w=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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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=111933745131301=2 Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
Hi! > and catting /proc/acpi/processor/CPU0/power gives > active state: C1 > max_cstate: C8 > bus master activity: > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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: 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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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: 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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
Hi! and catting /proc/acpi/processor/CPU0/power gives active state: C1 max_cstate: C8 bus master activity: 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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-kernelm=111933745131301w=2 Mvh Mats Johannesson -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
On Thu, 21 Jul 2005 20:49:59 +0200 Guillaume Chazarain wrote: > 2005/7/21, Voluspa <[EMAIL PROTECTED]>: > > > > 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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
2005/7/21, Voluspa <[EMAIL PROTECTED]>: > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
On Thu, 21 Jul 2005 20:14:32 +0200 Jesper Juhl wrote: > On 7/21/05, Voluspa <[EMAIL PROTECTED]> 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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
On 7/21/05, Voluspa <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
On 7/21/05, Voluspa [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
On Thu, 21 Jul 2005 20:14:32 +0200 Jesper Juhl wrote: On 7/21/05, Voluspa [EMAIL PROTECTED] 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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
2005/7/21, Voluspa [EMAIL PROTECTED]: 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
On Thu, 21 Jul 2005 20:49:59 +0200 Guillaume Chazarain wrote: 2005/7/21, Voluspa [EMAIL PROTECTED]: 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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
