# choice of absolute / relative freqs with est + p4tcc

Ian Smith smithi at nimnet.asn.au
Wed Jan 16 05:41:37 PST 2008

```On Wed, 16 Jan 2008, Tijl Coosemans wrote:
> On Wednesday 16 January 2008 05:29:47 Ian Smith wrote:
[..]
> > dev.cpu.0.freq_levels: 1200/-1 1100/-1 1000/-1 900/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1

> > dev.est.0.freq_settings: 1200/-1 1100/-1 1000/-1 900/-1 800/-1 600/-1

> > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1
> >
> > .. and find myself curious why 550 (1100 * .5) and 500 (1000 * .5)
> > would not be chosen when 525 (600 * .875) was, going by the comments:
> >
> > 	/*
> > 	 * Walk the set of all existing levels in reverse.  This is so we
> > 	 * create derived states from the lowest absolute settings first
> > 	 * and discard duplicates created from higher absolute settings.
> > 	 * For instance, a level of 50 Mhz derived from 100 Mhz + 50% is
> > 	 * preferable to 200 Mhz + 25% because absolute settings are more
> > 	 * efficient since they often change the voltage as well.
> > 	 */
> > and
> > 	/*
> > 	 * Insert the new level in sorted order.  If it is a duplicate of an
> > 	 * existing level (1) or has an absolute setting higher than the
> > 	 * existing level (2), do not add it.  We can do this since any such
> > 	 * level is guaranteed use less power.  For example (1), a level with
> > 	 * one absolute setting of 800 Mhz uses less power than one composed
> > 	 * of an absolute setting of 1600 Mhz and a relative setting at 50%.
> > 	 * Also for example (2), a level of 800 Mhz/75% is preferable to
> > 	 * 1600 Mhz/25% even though the latter has a lower total frequency.
> > 	 */
>
> It's because of (2) in the second comment. 550 and 500 likely use more
> power than 600 and 525, so it doesn't make sense to use them.

Ah, ok, thanks.

I hadn't really grokked (2) as it compares 600 with 400MHz, which seemed
'obviously' preferable, but for the wrong reason .. pardon the noise.

cheers, Ian

```

More information about the freebsd-acpi mailing list