From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 19:01:43 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBCED106566C for ; Mon, 11 May 2009 19:01:43 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0E18FC17 for ; Mon, 11 May 2009 19:01:42 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1328998mue.3 for ; Mon, 11 May 2009 12:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:organization:to :subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; bh=5tjV/4dfMMr0xhd3jhqEvQqXOvtBUV73imSrG9ks/KE=; b=gVcX5QNmTkWZ0hl07YpXhSTUWX0Ug0fP9Fp8olhGsKjW/3EPDQLXRsX0jdqUlVFt7E TxGf5kKSTaH11T90QC2Izvycul5BxxPERIvaGm/dQjh4sUbmN9Kb5ySaBv57Tdud2dKj H9aCfz6yngP7MWmLN/YG/DywAcuehHqh2C3B4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:organization:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=uFzAkLyw+tUFc69jhJeURCgJW/mnz1mUNthwhPfgH7UqGn5N9+Ny3k6rchvOT1eyIe gEwCYgZ0NRXQCbDA/MokO7mNNQGXcqy0mxI5kVopVJVHA9J+YHKXHLEVu5aKmNG0RA40 tjJ5hfIKWjWxcHcmATkWT/DSO5ajMyn/VRytw= Received: by 10.103.165.18 with SMTP id s18mr4386747muo.124.1242068501890; Mon, 11 May 2009 12:01:41 -0700 (PDT) Received: from onyx_hp.dhcp.loc ([92.50.244.69]) by mx.google.com with ESMTPS id j9sm5153848mue.21.2009.05.11.12.01.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 12:01:40 -0700 (PDT) From: Dmitry Kolosov Organization: Home To: freebsd-acpi@freebsd.org Date: Mon, 11 May 2009 22:59:13 +0400 User-Agent: KMail/1.11.3 (FreeBSD/7.2-STABLE; KDE/4.2.3; i386; ; ) References: <49FE1826.4060000@FreeBSD.org> In-Reply-To: <49FE1826.4060000@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905112259.14233.ivakras1@gmail.com> Subject: Re: Fighting for the power. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ivakras1@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 19:01:44 -0000 =F0=CF=CE=C5=C4=C5=CC=D8=CE=C9=CB 04 =CD=C1=D1 2009 02:18:14 Alexander Moti= n =D0=C9=D3=C1=CC=C9: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. >=20 > Modern systems, especially laptops, are implementing big number of=20 > power-saving technologies. Some of them are working automatically, other= =20 > have significant requirements and need special system tuning or=20 > trade-offs to be effectively used. >=20 > So here is the steps: >=20 > 1. CPU > CPU is the most consuming part of the system. Under the full load it > alone may consume more then 40W of power, but for real laptop usage the > most important is idle consumption. > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use = it: > P-states and throttling > Enabling powerd allows to effectively control CPU frequency/voltage > depending on CPU load. powerd on recent system can handle it quite > transparently. By default, frequency controlled via mix of EIST and > throttling technologies. First one controls both core frequency and > voltage, second - only core frequency. Both technologies give positive > power-saving effect. But effect of throttling is small and can be > completely hidden by using C2 state, that's why I recommend to disable > throttling control by adding to /boot/loader.conf: > hint.p4tcc.0.disabled=3D1 > hint.acpi_throttle.0.disabled=3D1 > In my case frequency/voltage control saves about 5W of idle power. > C-states > - C1 stops clock on some parts of CPU core during inactivity. It is > safe, cheap and supported by CPUs for ages. System uses C1 state by defau= lt. > - C2 state allows CPU to turn off all core clocks on idle. It is also > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > Use of C2 state can be enabled by adding to /etc/rc.conf: > performance_cx_lowest=3D"C2" > economy_cx_lowest=3D"C2" > Effect from this state is not so big when powerd is used, but still > noticeable, > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. The only solution for this problem is to use some > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=3D0 > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > It means that C3 state can't be effectively used when system is waking > up often. To increase inactivity periods we should reduce interrupt rate > as much as possible by adding to loader.conf: > kern.hz=3D100 > It may increase system response time a bit, but it is not significant > for laptop. Also we may avoid additional 128 interrupts per second per > core, by the cost of scheduling precision, with using i8254 timer also > for statistic collection purposes instead of RTC clock, by using another > newly added option: > hint.atrtc.0.clock=3D0 > As result, system has only 100 interrupts per core and CPUs are using C3 > with high efficiency: > %sysctl dev.cpu |grep cx > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.1.cx_lowest: C3 > dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us > Result of effective C3 state usage, comparing to C2+powerd, is about 2W. >=20 > 2. PCI devices > PCI bus provides method to control device power. For example, I have > completely no use for my FireWire controller and most of time - EHCI USB > controller. Disabling them allows me to save about 3W of power. To > disable all unneeded PCI devices you should build kernel without their > drivers and add to loader.conf: > hw.pci.do_power_nodriver=3D3 > To enable devices back all you need to do is just load their drivers as > modules. >=20 > 3. Radios > WiFi and Bluetooth adapters can consume significant power when used (up > to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling > them with mechanical switch on laptop case saves energy even when they > are not connected. >=20 > 4. HDA modem > I was surprised, but integrated HDA modem consumed about 1W of power > even when not used. I have used the most radical solution - removed it > mechanically from socket. Case surface in that area become much cooler. >=20 > 5. HDA sound > To reduce number of sound generated interrupts I have added to the > loader.conf: > hint.pcm.0.buffersize=3D65536 > hint.pcm.1.buffersize=3D65536 > hw.snd.feeder_buffersize=3D65536 > hw.snd.latency=3D7 >=20 > 6. HDD > First common recommendation is use tmpfs for temporary files. RAM is > cheap, fast and anyway with you. > Also you may try to setup automatic idle drive spin-down, but if it is > the only system drive you should be careful, as every spin-up reduces > drive's life time. > For several months (until I have bought SATA SSD) I have successfully > used SDHC card in built-in PCI sdhci card reader as main filesystem. On > random read requests it is much faster then HDD, but it is very slow on > random write. Same time it consumes almost nothing. USB drives could > also be used, but effect is much less as EHCI USB controller consumes > much power. > Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing > it completely saves 2W. >=20 > 7. SATA > Comparing to PATA, SATA interface uses differential signaling for data > transfer. To work properly it has to transmit pseudo-random scrambled > sequence even when idle. As you understand, that requires power. But > SATA implements two power saving modes: PARTIAL and SLUMBER. These modes > could be activated by either host or device if both sides support them. > PARTIAL mode just stops scrambling, but keeps neutral link state, resume > time is 50-100us. SLUMBER mode powers down interface completely, but > respective resume time is 3-10ms. > I have added minimal SATA power management to AHCI driver. There are > hint.ata.X.pm_level loader tunables can be used to control it now. > Setting it to 1 allows drive itself to initiate power saving, when it > wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and > SLUMBER transitions after every command completion. > Note that SATA power saving is not compatible with drive hot-swap, as > controller unable to detect drive presence when link is powered-down. > In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. >=20 > So what have I got? To monitor real system power consumption I am using > information provided by ACPI battery via `acpiconf -i0` command: >=20 > Original system: > Design capacity: 4800 mAh > Last full capacity: 4190 mAh > Technology: secondary (rechargeable) > Design voltage: 11100 mV > Capacity (warn): 300 mAh > Capacity (low): 167 mAh > Low/warn granularity: 32 mAh > Warn/full granularity: 32 mAh > Model number: Victoria > Serial number: 292 > Type: LION > OEM info: SIMPLO > State: discharging > Remaining capacity: 93% > Remaining time: 2:24 > Present rate: 1621 mA > Voltage: 12033 mV >=20 > Tuned system: > %acpiconf -i0 > Design capacity: 4800 mAh > Last full capacity: 4190 mAh > Technology: secondary (rechargeable) > Design voltage: 11100 mV > Capacity (warn): 300 mAh > Capacity (low): 167 mAh > Low/warn granularity: 32 mAh > Warn/full granularity: 32 mAh > Model number: Victoria > Serial number: 292 > Type: LION > OEM info: SIMPLO > State: discharging > Remaining capacity: 94% > Remaining time: 4:47 > Present rate: 826 mA > Voltage: 12231 mV >=20 > So I have really doubled my on-battery time by this tuning - 4:47 hours=20 > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows= =20 > XP on the same system, provides maximum 3:20 hours. >=20 My EC does not present rate and time info: 10:49pm][/home/onyx# acpiconf -i0 Design capacity: 6000 mAh Last full capacity: 3328 mAh Technology: secondary (rechargeable) Design voltage: 14800 mV Capacity (warn): 172 mAh Capacity (low): 104 mAh Low/warn granularity: 10 mAh Warn/full granularity: 25 mAh Model number: Primary Serial number: =20 Type: LION OEM info: Hewlett-Packard State: high=20 Remaining capacity: 100% Remaining time: unknown Present rate: unknown Voltage: 12522 mV Where to dig? I'm realy need at least 'present rate' to fight for the power= =2E. Also it is an error in capacity detection, i think. Any ideas?