Date: Mon, 11 May 2009 12:13:09 -0700 From: "Kevin Oberman" <oberman@es.net> To: ivakras1@gmail.com Cc: freebsd-acpi@freebsd.org Subject: Re: Fighting for the power. Message-ID: <20090511191309.79F0E1CC0B@ptavv.es.net> In-Reply-To: Your message of "Mon, 11 May 2009 22:59:13 %2B0400." <200905112259.14233.ivakras1@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Dmitry Kolosov <ivakras1@gmail.com> > Date: Mon, 11 May 2009 22:59:13 +0400 > Sender: owner-freebsd-acpi@freebsd.org > > Понедельник 04 мая 2009 02:18:14 Alexander Motin писали: > > 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. > > > > Modern systems, especially laptops, are implementing big number of > > power-saving technologies. Some of them are working automatically, other > > have significant requirements and need special system tuning or > > trade-offs to be effectively used. > > > > So here is the steps: > > > > 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=1 > > hint.acpi_throttle.0.disabled=1 > > 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 default. > > - 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="C2" > > economy_cx_lowest="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=0 > > 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=100 > > 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=0 > > 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. > > > > 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=3 > > To enable devices back all you need to do is just load their drivers as > > modules. > > > > 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. > > > > 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. > > > > 5. HDA sound > > To reduce number of sound generated interrupts I have added to the > > loader.conf: > > hint.pcm.0.buffersize=65536 > > hint.pcm.1.buffersize=65536 > > hw.snd.feeder_buffersize=65536 > > hw.snd.latency=7 > > > > 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. > > > > 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. > > > > So what have I got? To monitor real system power consumption I am using > > information provided by ACPI battery via `acpiconf -i0` command: > > > > 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 > > > > 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 > > > > So I have really doubled my on-battery time by this tuning - 4:47 hours > > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > > XP on the same system, provides maximum 3:20 hours. > > > > 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: > Type: LION > OEM info: Hewlett-Packard > State: high > 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.. Also it is an error in capacity detection, i think. Any ideas? Is the system connected to AC power when you issue the command? Many systems do not provide this information unless they are no battery power. Thy may also need to have been on battery for at least a minute or two to calculate drain rate. (Also, that battery is getting fairly old. It has only 55% of it's designed capacity.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090511191309.79F0E1CC0B>