From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 14 16:31:33 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 85D10EBC; Sun, 14 Jul 2013 16:31:33 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 37C17859; Sun, 14 Jul 2013 16:31:32 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r6EGVWMv061872; Sun, 14 Jul 2013 10:31:32 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r6EGVWAU061869; Sun, 14 Jul 2013 10:31:32 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 14 Jul 2013 10:31:32 -0600 (MDT) From: Warren Block To: Ian Smith Subject: Re: Hyper mode for powerd In-Reply-To: <20130714161717.Y12860@sola.nimnet.asn.au> Message-ID: References: <20130707003651.Y26496@sola.nimnet.asn.au> <20130709145722.U61164@sola.nimnet.asn.au> <20130710200113.J23480@sola.nimnet.asn.au> <20130714161717.Y12860@sola.nimnet.asn.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 14 Jul 2013 10:31:32 -0600 (MDT) Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 16:31:33 -0000 On Sun, 14 Jul 2013, Ian Smith wrote: > What powerd(8) could really use is an update to its man page (or a page > in the handbook, or wiki?) suggesting some reasonable defaults for the > range of hardware nowadays running it. Difficulty: finding "reasonable" defaults. But given the values, I would be willing to add them to that page. > I guess powerd(8) would be also a good place to mention the advantage of > turning off p4tcc and acpi_throttle in loader.conf, as at least a step > towards deprecating their use with powerd? [Kevin, what do you think?] Before that, there should probably be some benchmarks, both for performance and power usage. Those last results I posted left both settings at the default (enabled). I don't know if they do any harm that way. Again, a power usage benchmark would be interesting. A heat level benchmark ought to be possible with the built-in temperature sensors. > > > Hunting away. > > > > Is that a bad thing, though? Effectively, it's just PWM, if you see what I > > mean. > > I do, but to extend that analogy, compare an inverter with squarewave > output to one using a stepped pseudo-sine wave, as most non-pure-sine > inverters do today, much smoother and more efficient too. I don't know > the actual cost of changing freqs via sysctl, but suspect less often and > smaller stepsizes are going to be more efficient and less likely to > shift to a wildly inappropriate freq for load. Perhaps my mechanical > engineering bent worries about wear and tear on the 'gearbox', as it > were, which of course we know to be a non-issue electronically :) I thought that was what Kevin was saying, that shifting to full idle or full throttle was the most efficient. Even if there is a higher cost to larger frequency changes, it may be more than offset by power savings or processing capacity. > > The same periodic daily test as before, again with the first run discarded to > > load the cache. > > > > powerd -a hyper -n hyper -p 50 -v > /tmp/powerd.log > > 977.44 real 47.79 user 238.48 sys > > > > powerd -a hadp -n hadp -p 50 -v > /tmp/powerd.log > > 874.18 real 28.89 user 140.00 sys > > Well hadp here gets the job done more quickly at any rate, both > absolutely and in terms of system and user time. Possibly due to the slower throttling down when the system is detected to be idle. > If you're really burning up to hack on powerd :) a timestamp including > milliseconds on the -v output lines (which might be cut to two lines max > per change) would make it far easier to see what was happening, when .. This really has me thinking more about benchmarks now.