Hyper mode for powerd
Ian Smith
smithi at nimnet.asn.au
Sun Jul 14 07:40:44 UTC 2013
On Wed, 10 Jul 2013 13:43:56 -0600, Warren Block wrote:
> On Wed, 10 Jul 2013, Ian Smith wrote:
[..]
> > > Interesting point. 100mS is a perceptible lag.
> >
> > Maybe just. On that beast I think you could use 50ms with no noticeable
> > powerd CPU usage, maybe even 25ms. In fact I think doing just that with
> > hadp mode might get you all the interactive responsiveness you want, and
> > still let powerd use a range of freqs as required. Playing with -r and
> > -i will also alter the responsiveness curve quite a bit.
> >
> > With it then testing load and increasing frequency 5 times as often, on
> > full load it should shift up 5 times more quickly, and hadp mode already
> > shifts freq up by a factor of 4 on each poll_interval, so it should get
> > from 1600 to 3601 in one! iteration, and even if using p4tcc/throttling,
> > from 200 to 3601 in only two or three steps (200 x 4 = 800, 800 x 4 =
> > 3200) with even three steps then taking only 150ms, well inside your
> > current 250ms interval. Maybe give that a try?
>
> Wow! -r 50 with either hadp or hyper mode feels fine interactively.
You sound surprised, but I'm not. Nate Lawson introduced powerd at
FreeBSD 6.0, using a Thinkpad T23 at that time, 1133/733 MHz, and 250mS
was a reasonable default for laptops then. In fact, I bought my first
2ndhand T23 around 6.1-RELEASE precisely because Nate was working on
ACPI and cpufreq etc, and the T23 was then one of the few machines that
reliably suspended and resumed (and still is!), a must for me.
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. When mav@ added hiadaptive mode
I was quite skeptical at first, and of course it proved useless for the
two-speed T23, which would jump to max speed at the drop of a hat but
then take forever to shuffle back down to lower speed, but is clearly
advantageous for more modern machines - esp. with more frequent polling.
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?]
> > > Timing 'periodic daily' now with a full cache and powerd not running:
> > > 995.53 real 28.15 user 132.17 sys
> > >
> > > With 'powerd -a hyper -n hyper -v > /tmp/powerd.log':
> > > 2322.06 real 58.72 user 305.22 sys
> > >
> > > Load varied enough that it would drop to 200MHz quite often. Picking a
> > > random part of the log:
[..]
> > > changing clock speed from 3601 MHz to 200 MHz
> > > load 4%, current freq 200 MHz (26), wanted freq 200 MHz
> > > now operating on AC power; changing frequency to 3601 MHz
> > > load 20%, current freq 200 MHz (26), wanted freq 3601 MHz
> > > changing clock speed from 200 MHz to 3601 MHz
> > > now operating on AC power; changing frequency to 200 MHz
> > > load 3%, current freq 3601 MHz ( 0), wanted freq 200 MHz
>
> > 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 :)
> > Over twice as long to run. Maybe now try at 50ms in hadp mode and you'll
> > have a good idea how fast that runs, and how it feels.
>
> 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.
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 ..
cheers, Ian
More information about the freebsd-acpi
mailing list