mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marc Ballarin <Ballarin.Marc@gmx.de>
To: linux-kernel@vger.kernel.org
Subject: Power consumption HZ250 vs. HZ1000
Date: Mon, 25 Jul 2005 16:13:33 +0200	[thread overview]
Message-ID: <20050725161333.446fe265.Ballarin.Marc@gmx.de> (raw)

Hi,
I did some measurements in order to compare power drain with HZ250 and
HZ1000.
To measure the actual drain, I used the "smart" battery's internal measurement.
(Available with acpi-sbs in /proc/acpi/sbs/SBS0/SB0/state.)
No clue how accurate this is.

Here some battery details, in case someone knows:
charge reporting error:  25%
SB specification:        v1.1 (with PEC)
manufacturer name:       Panasonic
manufacture date:        2004-11-27
device name:             02ZL
device chemistry:        Lion

Kernel: 2.6.13-rc3-mm1 + acpi-sbs

CPU:
cpu family	: 6
model		: 13
model name	: Intel(R) Pentium(R) M processor 1.60GHz
stepping		: 6

The "ondemand" governor was running, using acpi_cpufreq. (Idle at 600MHz).

Systems was running X11/KDE to get a more or less realistic scenario. No
cron jobs, network traffic or additional applications. WLAN and built-in
display were disabled completely, all fans and LEDs were off, internal hard
disc was running. Additional peripherals: external keyboard, mouse, display
and externally-powered hard disk (USB).

The results are quite simple:
In both configurations the current settles between 727-729 mA
(Voltage ~16.5 V).

Some issues:

- C-states look strange:
active state:            C2
max_cstate:              C8
bus master activity:     00887fff
states:
    C1:                  type[C1] promotion[C2] demotion[--]   latency[000] usage[00000010]
  *C2:                  type[C2] promotion[C3] demotion[C1] latency[001] usage[01367471]
    C3:                  type[C3] promotion[--]   demotion[C2] latency[085] usage[00000000]

- I don't know, how much polling of the battery affects results. Reads always
block for ~10 seconds, and I used this behaviour for rate-limiting.

- Is this approach valid at all?

- I could repeat the test in single user mode with internal hard disc turned off.

Regards

             reply	other threads:[~2005-07-25 14:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-25 14:13 Marc Ballarin [this message]
2005-07-25 15:53 ` Pavel Machek
2005-07-25 19:02   ` Marc Ballarin
2005-07-26 23:28     ` dean gaudet
2005-07-27  7:51   ` Tony Lindgren
2005-07-27  8:00     ` Pavel Machek
2005-07-27 11:20       ` Tony Lindgren
2005-07-25 20:14 ` Bill Davidsen
2005-07-26  5:08 Brown, Len

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050725161333.446fe265.Ballarin.Marc@gmx.de \
    --to=ballarin.marc@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®