Status of X86_P4_CLOCKMOD?

Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Tue, Feb 21, 2006 at 10:20:04PM -0500, Dmitry Torokhov wrote:
> On Tuesday 21 February 2006 22:10, Adrian Bunk wrote:
> > On Wed, Feb 22, 2006 at 03:44:38AM +0100, Herbert Poetzl wrote:
> > > 
> > >  config X86_P4_CLOCKMOD
> > > 	depends on EMBEDDED
> > 
> > This one is an x86_64 only issue, and yes, it's wrong.
> 
> That's for P4, not X86_64... And since P4 clock modulation does not provide
> almost any energy savings it was "hidden" under embedded.

But the EMBEDDED dependency is only on x86_64:

arch/i386/kernel/cpu/cpufreq/Kconfig:
config X86_P4_CLOCKMOD
        tristate "Intel Pentium 4 clock modulation"
        select CPU_FREQ_TABLE
        help

arch/x86_64/kernel/cpufreq/Kconfig:
config X86_P4_CLOCKMOD
        tristate "Intel Pentium 4 clock modulation"
        depends on EMBEDDED
        help

And if the option is mostly useless, what is it good for?

> Dmitry

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Dave Jones]

On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:

 > > > >  config X86_P4_CLOCKMOD
 > > > > 	depends on EMBEDDED
 > > > 
 > > > This one is an x86_64 only issue, and yes, it's wrong.
 > > 
 > > That's for P4, not X86_64... And since P4 clock modulation does not provide
 > > almost any energy savings it was "hidden" under embedded.
 > 
 > But the EMBEDDED dependency is only on x86_64:
 > 
 > arch/i386/kernel/cpu/cpufreq/Kconfig:
 > config X86_P4_CLOCKMOD
 >         tristate "Intel Pentium 4 clock modulation"
 >         select CPU_FREQ_TABLE
 >         help
 > 
 > arch/x86_64/kernel/cpufreq/Kconfig:
 > config X86_P4_CLOCKMOD
 >         tristate "Intel Pentium 4 clock modulation"
 >         depends on EMBEDDED
 >         help
 > 
 > And if the option is mostly useless, what is it good for?

It's sometimes useful in cases where the target CPU doesn't have any better
option (Speedstep/Powernow).  The big misconception is that it
somehow saves power & increases battery life. Not so.
All it does is 'not do work so often'.  The upside of this is
that in some situations, we generate less heat this way.

It's really of limited practical use, but occasionally, we find
some users that do find it handy.  (One case I heard was someone
with a server farm that generated lots of heat, but at nighttime,
he could throttle that back, which resulted in a drop in overall
temperature in the serverroom -- no numbers to back it up though,
just anecdotes).  

As to the difference of EMBEDDED.. on 32bit, there's a lot more
systems without speedstep/powernow, so it makes more sense to
make it more widely available.  Nearly all AMD64/EM64T have 
some form of speed-scaling which is more effective than p4-clockmod,
which is why I assume it's set that way.

Andi can probably confirm the thinking on that one, as I think
he added it when x86-64 first started supporting cpufreq.

		Dave

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Thursday 23 February 2006 21:41, Dave Jones wrote:

> It's really of limited practical use, but occasionally, we find
> some users that do find it handy.  (One case I heard was someone
> with a server farm that generated lots of heat, but at nighttime,
> he could throttle that back, which resulted in a drop in overall
> temperature in the serverroom -- no numbers to back it up though,
> just anecdotes).

Perhaps they should just turn some computers off over night then.

Another drawback is that adds very long latencies. e.g. when it is
enabled you can really end up with desktops where the mouse
doesn't react for a very visible to humans delay.

And it'll mess up kernel timing in general.

> As to the difference of EMBEDDED.. on 32bit, there's a lot more
> systems without speedstep/powernow, so it makes more sense to
> make it more widely available.  Nearly all AMD64/EM64T have
> some form of speed-scaling which is more effective than p4-clockmod,
> which is why I assume it's set that way.
>
> Andi can probably confirm the thinking on that one, as I think
> he added it when x86-64 first started supporting cpufreq.

It should IMHO depend on EMBEDDED on i386 too because
the uses are extremly specialized (if there are any) and most users setting it 
probably set it by mistake because they misunderstand it.

-Andi

Re: Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Fri, Feb 24, 2006 at 12:15:59AM +0100, Andi Kleen wrote:
> On Thursday 23 February 2006 21:41, Dave Jones wrote:
>...
> > As to the difference of EMBEDDED.. on 32bit, there's a lot more
> > systems without speedstep/powernow, so it makes more sense to
> > make it more widely available.  Nearly all AMD64/EM64T have
> > some form of speed-scaling which is more effective than p4-clockmod,
> > which is why I assume it's set that way.
> >
> > Andi can probably confirm the thinking on that one, as I think
> > he added it when x86-64 first started supporting cpufreq.
> 
> It should IMHO depend on EMBEDDED on i386 too because
> the uses are extremly specialized (if there are any) and most users setting it 
> probably set it by mistake because they misunderstand it.

EMBEDDED is the wrong option, since the semantics of embedded is "show 
more options to allow additional space savings". It is not and should 
not be abused as an option to hide random options from users.

Currently, EXPERIMENTAL is nearer to what suits X86_P4_CLOCKMOD, and it 
seems we really need an ADVANCED_USER option for such options.

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Friday 24 February 2006 00:33, Adrian Bunk wrote:

> EMBEDDED is the wrong option, since the semantics of embedded is "show
> more options to allow additional space savings". It is not and should
> not be abused as an option to hide random options from users.

I disagree. And I originally added most EMBEDDED users to the kernel.
The purpose I added it for was to hide options that only useful
for a very limited userbase but cause big or subtle trouble when set
wrong. P4_CLOCKMOD clearly qualifies.

-Andi

Re: Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Fri, Feb 24, 2006 at 12:55:30AM +0100, Andi Kleen wrote:
> On Friday 24 February 2006 00:33, Adrian Bunk wrote:
> 
> > EMBEDDED is the wrong option, since the semantics of embedded is "show
> > more options to allow additional space savings". It is not and should
> > not be abused as an option to hide random options from users.
> 
> I disagree. And I originally added most EMBEDDED users to the kernel.
> The purpose I added it for was to hide options that only useful
> for a very limited userbase but cause big or subtle trouble when set
> wrong. P4_CLOCKMOD clearly qualifies.

This matches neither the description of the EMBEDDED option nor all 
other usages in the kernel I have seen until now.

We need an additional option for such cases, but overloading EMBEDDED 
with more than one meaning is definitely not a good idea.

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Friday 24 February 2006 03:39, Adrian Bunk wrote:

> We need an additional option for such cases, but overloading EMBEDDED 
> with more than one meaning is definitely not a good idea.

I think it works just fine.

-Andi

Re: Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Fri, Feb 24, 2006 at 03:42:02AM +0100, Andi Kleen wrote:
> On Friday 24 February 2006 03:39, Adrian Bunk wrote:
> 
> > We need an additional option for such cases, but overloading EMBEDDED 
> > with more than one meaning is definitely not a good idea.
> 
> I think it works just fine.

It works in the way that users don't see this option.

Both for this purpose, BROKEN or even simply removing the option would 
work equally well...

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Thu, Feb 23, 2006, Dave Jones wrote:
> On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
>  > And if the option is mostly useless, what is it good for?
> 
> It's sometimes useful in cases where the target CPU doesn't have any better
> option (Speedstep/Powernow).  The big misconception is that it
> somehow saves power & increases battery life. Not so.
> All it does is 'not do work so often'.  The upside of this is
> that in some situations, we generate less heat this way.

Doesn't less heat imply less power consumption?

Anyway, I have P4 in my desktop machine, and the reason
why I tried to use P4 clock modulation was to reduce fan noise,
and save some energy. And yes, fan noise was reduced.

The reason why I turned it off again was that I couldn't
find any governor or userspace daemon that would work
in a sensible way with the high latency of the P4
clock modulation.
What I think could work:

- after some minutes of idling without user activity
  go into lowest power mode (could be triggered
  from xscreensaver)
- at the slightest hint of user activity or CPU load jump
  back to max performance mode
(- optionally use intermediate clock mod steps for
  non-interactive loads, but I'm not convinced it's
  worth it)

P4 clockmod certainly sucks compared to Speedstep,
but IMHO it is still potentially useful for the average
desktop PC user (at least those many who let their PCs
run 24/7, but 90% idle and unused).


Johannes

Re: Status of X86_P4_CLOCKMOD?

[Dave Jones]

On Sat, Feb 25, 2006 at 02:57:22AM +0100, Johannes Stezenbach wrote:
 > On Thu, Feb 23, 2006, Dave Jones wrote:
 > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
 > >  > And if the option is mostly useless, what is it good for?
 > > 
 > > It's sometimes useful in cases where the target CPU doesn't have any better
 > > option (Speedstep/Powernow).  The big misconception is that it
 > > somehow saves power & increases battery life. Not so.
 > > All it does is 'not do work so often'.  The upside of this is
 > > that in some situations, we generate less heat this way.
 > 
 > Doesn't less heat imply less power consumption?

Not really.  The only energy you're saving is that your CPU fan
will turn slightly slower, which is probably going to be < 1W
of difference.  Generated heat drop in a large room of servers
*may* mean the aircon has less to do, but I'd be surprised if
it made a noticable difference.

 > - after some minutes of idling without user activity
 >   go into lowest power mode (could be triggered
 >   from xscreensaver)
 > - at the slightest hint of user activity or CPU load jump
 >   back to max performance mode
 > (- optionally use intermediate clock mod steps for
 >   non-interactive loads, but I'm not convinced it's
 >   worth it)

You should be able to modify cpuspeed or some other userspace
governor to do this quite easily.

		Dave

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Fri, Feb 24, 2006, Dave Jones wrote:
> On Sat, Feb 25, 2006 at 02:57:22AM +0100, Johannes Stezenbach wrote:
>  > On Thu, Feb 23, 2006, Dave Jones wrote:
>  > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
>  > >  > And if the option is mostly useless, what is it good for?
>  > > 
>  > > It's sometimes useful in cases where the target CPU doesn't have any better
>  > > option (Speedstep/Powernow).  The big misconception is that it
>  > > somehow saves power & increases battery life. Not so.
>  > > All it does is 'not do work so often'.  The upside of this is
>  > > that in some situations, we generate less heat this way.
>  > 
>  > Doesn't less heat imply less power consumption?
> 
> Not really.  The only energy you're saving is that your CPU fan
> will turn slightly slower, which is probably going to be < 1W
> of difference.

I thought the fan turns slower because the CPU generates
less heat, which in turn is because it consumes less
electrical energy.

If someone has done measurements I'd be interested to
know the numbers about the actual power savings which
can be achieved by using P4 clock mod. I don't expect
it to be much, but I bet it's more than 1W.


Johannes

Re: Status of X86_P4_CLOCKMOD?

[Wes Felter]

Johannes Stezenbach wrote:

> If someone has done measurements I'd be interested to
> know the numbers about the actual power savings which
> can be achieved by using P4 clock mod. I don't expect
> it to be much, but I bet it's more than 1W.

Clock modulation can reduce power by 40W on a 3.6GHz Xeon when the 
system is running a high-power application (e.g. Linpack). (It also 
reduces performance by a factor of 6-10). Clock modulation saves no 
power at all during idle.

Wes Felter - wesley@felter.org

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote:
> On Thu, Feb 23, 2006, Dave Jones wrote:
> > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> >  > And if the option is mostly useless, what is it good for?
> > 
> > It's sometimes useful in cases where the target CPU doesn't have any better
> > option (Speedstep/Powernow).  The big misconception is that it
> > somehow saves power & increases battery life. Not so.
> > All it does is 'not do work so often'.  The upside of this is
> > that in some situations, we generate less heat this way.
> 
> Doesn't less heat imply less power consumption?

Not in this case no.

> P4 clockmod certainly sucks compared to Speedstep,
> but IMHO it is still potentially useful for the average
> desktop PC user (at least those many who let their PCs
> run 24/7, but 90% idle and unused).

I don't think so no. The latencies make it unusable.

-Andi
 

Re: Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Sat, Feb 25, 2006 at 05:27:01AM +0100, Andi Kleen wrote:
> On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote:
> > On Thu, Feb 23, 2006, Dave Jones wrote:
> > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> > >  > And if the option is mostly useless, what is it good for?
> > > 
> > > It's sometimes useful in cases where the target CPU doesn't have any better
> > > option (Speedstep/Powernow).  The big misconception is that it
> > > somehow saves power & increases battery life. Not so.
> > > All it does is 'not do work so often'.  The upside of this is
> > > that in some situations, we generate less heat this way.
> > 
> > Doesn't less heat imply less power consumption?
> 
> Not in this case no.
>...

Sorry for the dumb question, but how could this work physically?

If a computer produces less heat with the same power consumption, what 
happens with the other energy?

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Dominik Brodowski]

On Sat, Feb 25, 2006 at 01:53:26PM +0100, Adrian Bunk wrote:
> > > Doesn't less heat imply less power consumption?
> > 
> > Not in this case no.
> >...
> 
> Sorry for the dumb question, but how could this work physically?
> 
> If a computer produces less heat with the same power consumption, what 
> happens with the other energy?

No. Let's do the math (again), and (again) for the actual values of an Intel
Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of
physics, logic and mathematics apply to _all_ processors.

Power consumption in idle state C2 (Stop-Grant state)	 7.3 W
Power consumption when "skipping instructions"
	because of throttling (Stop-Grant state)	 7.3 W

Power consumption when doing work			22.0 W


This means that if the processor idle percentage is _larger_ than (1 -
throttling rate), throttling has no effect at all.


Now, let's assume there is some work for the CPU to do which keeps it busy
for one second @ 1.4 GHz. How much energy is needed to get this work done?

0% throttling:		22 Ws	(1s)
25% throttling:		24 Ws	(1.3s)
50% throttling:		29 Ws	(2s)
75% throttling:		44 Ws	(4s)


Now let's also assume there is nothing else to do during a span of four
seconds: then, independent of the throttling setting, the CPU power
consumption is 44 Ws for these four seconds.


However: for the 75% throttling state, the CPU only produces 11 W of heat
_all the time_ -- this means, the fan or air conditioning must only consider
11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool
that sufficiently, the fan _may_ need to run faster, which consumes more
energy than is saved by only having to cool 7.3 W (instead of 11W) the other
three seconds.


So: P4-clockmod style throttling only makes sense if either

a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or

b) the load varies significantly over time in a manner which has effect on
   the fan, and where the latency induced by throttling doesn't matter.


	Dominik

Re: Status of X86_P4_CLOCKMOD?

[Pavel Machek]

Hi!

> > > Not in this case no.
> > >...
> > 
> > Sorry for the dumb question, but how could this work physically?
> > 
> > If a computer produces less heat with the same power consumption, what 
> > happens with the other energy?
> 
> No. Let's do the math (again), and (again) for the actual values of an Intel
> Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of
> physics, logic and mathematics apply to _all_ processors.
> 
> Power consumption in idle state C2 (Stop-Grant state)	 7.3 W
> Power consumption when "skipping instructions"
> 	because of throttling (Stop-Grant state)	 7.3 W
> 
> Power consumption when doing work			22.0 W
> 
> 
> This means that if the processor idle percentage is _larger_ than (1 -
> throttling rate), throttling has no effect at all.
> 
> 
> Now, let's assume there is some work for the CPU to do which keeps it busy
> for one second @ 1.4 GHz. How much energy is needed to get this work done?
> 
> 0% throttling:		22 Ws	(1s)
> 25% throttling:		24 Ws	(1.3s)
> 50% throttling:		29 Ws	(2s)
> 75% throttling:		44 Ws	(4s)
> 
> 
> Now let's also assume there is nothing else to do during a span of four
> seconds: then, independent of the throttling setting, the CPU power
> consumption is 44 Ws for these four seconds.
> 
> 
> However: for the 75% throttling state, the CPU only produces 11 W of heat
> _all the time_ -- this means, the fan or air conditioning must only consider
> 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool
> that sufficiently, the fan _may_ need to run faster, which consumes more
> energy than is saved by only having to cool 7.3 W (instead of 11W) the other
> three seconds.
> 
> 
> So: P4-clockmod style throttling only makes sense if either
> 
> a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or
> 
> b) the load varies significantly over time in a manner which has effect on
>    the fan, and where the latency induced by throttling doesn't matter.

c) your load is something like game of doom, where you want
  to play for half an hour with least power consumed. You
  don't really need 1000 fps, 100 fps is enough.
						Pavel
-- 
Thanks, Sharp!

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Sat, Feb 25, 2006 at, Dominik Brodowski wrote:
> On Sat, Feb 25, 2006 at 01:53:26PM +0100, Adrian Bunk wrote:
> > > > Doesn't less heat imply less power consumption?
> > > 
> > > Not in this case no.
> > >...
> > 
> > Sorry for the dumb question, but how could this work physically?
> > 
> > If a computer produces less heat with the same power consumption, what 
> > happens with the other energy?
> 
> No. Let's do the math (again), and (again) for the actual values of an Intel
> Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of
> physics, logic and mathematics apply to _all_ processors.

Do you have the numbers for a Pentium(R) 4 HT? (I couldn't find
anything substantial with google.) Especially C2 vs. C2 + throttling?
Because the way I remember having read somewhere, the idle
(C2) power consumption of the P4 is significantly higher
than with the Pentium(R) M.

> Power consumption in idle state C2 (Stop-Grant state)	 7.3 W
> Power consumption when "skipping instructions"
> 	because of throttling (Stop-Grant state)	 7.3 W
> 
> Power consumption when doing work			22.0 W
> 
> 
> This means that if the processor idle percentage is _larger_ than (1 -
> throttling rate), throttling has no effect at all.

On a Pentium(R) M, but how about P4? The two have very different
architectures, don't they?

> Now, let's assume there is some work for the CPU to do which keeps it busy
> for one second @ 1.4 GHz. How much energy is needed to get this work done?
> 
> 0% throttling:		22 Ws	(1s)
> 25% throttling:		24 Ws	(1.3s)
> 50% throttling:		29 Ws	(2s)
> 75% throttling:		44 Ws	(4s)
> 
> 
> Now let's also assume there is nothing else to do during a span of four
> seconds: then, independent of the throttling setting, the CPU power
> consumption is 44 Ws for these four seconds.
> 
> 
> However: for the 75% throttling state, the CPU only produces 11 W of heat
> _all the time_ -- this means, the fan or air conditioning must only consider
> 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool
> that sufficiently, the fan _may_ need to run faster, which consumes more
> energy than is saved by only having to cool 7.3 W (instead of 11W) the other
> three seconds.

This is all fine, but why would anyone use throttling when the
CPU has work to do (except for thermal emergency throttling)?

> So: P4-clockmod style throttling only makes sense if either
> 
> a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or
> 
> b) the load varies significantly over time in a manner which has effect on
>    the fan, and where the latency induced by throttling doesn't matter.

Maybe my previous mails were not clear enough: The goal is to
reduce idle power consumption (and by that fan noise). The PC
is running but is idle, e.g just listening for possible incoming
jabber messages or whatever.

When I experimented with P4-clockmod some time ago, I observed
that the fan noise was reduced when I left the box run idle
with clockmod set to maximum throttling. I thought this was
a good thing.

Anyway, 2.6.16-rc4 p4-clockmod driver doesn't work with my CPU
anymore (booted with cpufreq.debug=7):

CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz stepping 09
Checking 'hlt' instruction... OK.
...
cpufreq-core: trying to register driver p4-clockmod
cpufreq-core: adding CPU 0
p4-clockmod: has errata -- disabling frequencies lower than 2ghz
speedstep-lib: x86: f, model: 2
speedstep-lib: ebx value is 9, x86_mask is 9
speedstep-lib: P4 - MSR_EBC_FREQUENCY_ID: 0xd12000d 0x0
speedstep-lib: P4 - FSB 200000 kHz; Multiplier 13; Speed 2600000 kHz
freq-table: setting show_table for cpu 0 to b04be620
freq-table: table entry 0 is invalid, skipping
freq-table: table entry 1 is invalid, skipping
freq-table: table entry 2 is invalid, skipping
freq-table: table entry 3 is invalid, skipping
freq-table: table entry 4 is invalid, skipping
freq-table: table entry 5 is invalid, skipping
freq-table: table entry 6 is invalid, skipping
freq-table: table entry 7 is invalid, skipping
freq-table: table entry 8 is invalid, skipping
cpufreq-core: initialization failed
cpufreq-core: no CPU initialized for driver p4-clockmod
cpufreq-core: unregistering CPU 0


Johannes

Re: Status of X86_P4_CLOCKMOD?

[Dominik Brodowski]

Hi,

On Sun, Feb 26, 2006 at 09:39:41PM +0100, Johannes Stezenbach wrote:
> > No. Let's do the math (again), and (again) for the actual values of an Intel
> > Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of
> > physics, logic and mathematics apply to _all_ processors.
> 
> Do you have the numbers for a Pentium(R) 4 HT? (I couldn't find
> anything substantial with google.) Especially C2 vs. C2 + throttling?
> Because the way I remember having read somewhere, the idle
> (C2) power consumption of the P4 is significantly higher
> than with the Pentium(R) M.

Unfortunately, I do not have these numbers present. You can check the
processor specification sheets at Intel's website, though.


> > Power consumption in idle state C2 (Stop-Grant state)	 7.3 W
> > Power consumption when "skipping instructions"
> > 	because of throttling (Stop-Grant state)	 7.3 W
> > 
> > Power consumption when doing work			22.0 W
> > 
> > 
> > This means that if the processor idle percentage is _larger_ than (1 -
> > throttling rate), throttling has no effect at all.
> 
> On a Pentium(R) M, but how about P4? The two have very different
> architectures, don't they?

They have different architectures, but again -- AFAIK -- throttling means STPCLK
is stopped, which is equivalent to the Stop-Grant state. And that's what's
usually entered in C2-type idle sleep.

> > However: for the 75% throttling state, the CPU only produces 11 W of heat
> > _all the time_ -- this means, the fan or air conditioning must only consider
> > 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool
> > that sufficiently, the fan _may_ need to run faster, which consumes more
> > energy than is saved by only having to cool 7.3 W (instead of 11W) the other
> > three seconds.
> 
> This is all fine, but why would anyone use throttling when the
> CPU has work to do (except for thermal emergency throttling)?

That's exactly the opposite of what you should do, if idling works at least
reasonably well: only enter throttling if the CPU has some substancial
workload.

> > So: P4-clockmod style throttling only makes sense if either
> > 
> > a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or
> > 
> > b) the load varies significantly over time in a manner which has effect on
> >    the fan, and where the latency induced by throttling doesn't matter.
> 
> Maybe my previous mails were not clear enough: The goal is to
> reduce idle power consumption (and by that fan noise). The PC
> is running but is idle, e.g just listening for possible incoming
> jabber messages or whatever.

Most probably, the idle handler can't make use of the Stop-Grant state (C2)
here, so this is case a) noted above.

> p4-clockmod: has errata -- disabling frequencies lower than 2ghz


	Dominik

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Sun, Feb 26, 2006, Dominik Brodowski wrote:
> On Sun, Feb 26, 2006 at 09:39:41PM +0100, Johannes Stezenbach wrote:
> > 
> > Do you have the numbers for a Pentium(R) 4 HT? (I couldn't find
> > anything substantial with google.) Especially C2 vs. C2 + throttling?
> > Because the way I remember having read somewhere, the idle
> > (C2) power consumption of the P4 is significantly higher
> > than with the Pentium(R) M.
> 
> Unfortunately, I do not have these numbers present. You can check the
> processor specification sheets at Intel's website, though.

Went to the Intel(R) website, searched for half an hour, found many
docs but none that gives useful information about this, gave up. :-(

> > > So: P4-clockmod style throttling only makes sense if either
> > > 
> > > a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or
> > 
> > Maybe my previous mails were not clear enough: The goal is to
> > reduce idle power consumption (and by that fan noise). The PC
> > is running but is idle, e.g just listening for possible incoming
> > jabber messages or whatever.
> 
> Most probably, the idle handler can't make use of the Stop-Grant state (C2)
> here, so this is case a) noted above.

Hm.

Thanks,
Johannes

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Saturday 25 February 2006 13:53, Adrian Bunk wrote:
On Sat, Feb 25, 2006 at 05:27:01AM +0100, Andi Kleen wrote:
> > On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote:
> > > On Thu, Feb 23, 2006, Dave Jones wrote:
> > > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> > > >  > And if the option is mostly useless, what is it good for?
> > > >
> > > > It's sometimes useful in cases where the target CPU doesn't have any
> > > > better option (Speedstep/Powernow).  The big misconception is that it
> > > > somehow saves power & increases battery life. Not so.
> > > > All it does is 'not do work so often'.  The upside of this is
> > > > that in some sit> uations, we generate less heat this way.
> > >
> > > Doesn't less heat imply less power consumption?
> >
> > Not in this case no.
> >...
>
> Sorry for the dumb question, but how could this work physically?
>
> If a computer produces less heat with the same power consumption, what
> happens with the other energy?

It's consumed over a longer time. In throttling mode the CPU skips
doing work on clock ticks. This temporarily lowers the local heat
that comes from switching transistors, but if the system has some 
computation to do it will take longer to do it until the machine can go to 
idle again and do real power saving.

This means on a global scale you're not saving anything, in fact
you're wasting more power.

There are sometimes secondary effects like the air condition
of your server room may consume less power if the peak
heat is lower, but they likely only apply in very specialized 
circumstances.

It's basically only a last measure that the CPU tries to cool itself
down a bit before forcibly shutting down. It's also not really
designed to be used in normal operation, so you end up
with problems like TSC timing being wrong or extremly
long user visible latencies to switch back to normal operation.

-Andi

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Sat, Feb 25, 2006, Andi Kleen wrote:
> On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote:
> > P4 clockmod certainly sucks compared to Speedstep,
> > but IMHO it is still potentially useful for the average
> > desktop PC user (at least those many who let their PCs
> > run 24/7, but 90% idle and unused).
> 
> I don't think so no. The latencies make it unusable.

I tried to explain that I think one can use it in a way
so the latencies are not a big issue. One must
just accept that it needs different policy than
Speedstep etc.


Johannes

Re: Status of X86_P4_CLOCKMOD?

[Matt Mackall]

On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
> On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> 
>  > > > >  config X86_P4_CLOCKMOD
>  > > > > 	depends on EMBEDDED
>  > > > 
>  > > > This one is an x86_64 only issue, and yes, it's wrong.
>  > > 
>  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
>  > > almost any energy savings it was "hidden" under embedded.
>  > 
>  > But the EMBEDDED dependency is only on x86_64:
>  > 
>  > arch/i386/kernel/cpu/cpufreq/Kconfig:
>  > config X86_P4_CLOCKMOD
>  >         tristate "Intel Pentium 4 clock modulation"
>  >         select CPU_FREQ_TABLE
>  >         help
>  > 
>  > arch/x86_64/kernel/cpufreq/Kconfig:
>  > config X86_P4_CLOCKMOD
>  >         tristate "Intel Pentium 4 clock modulation"
>  >         depends on EMBEDDED
>  >         help
>  > 
>  > And if the option is mostly useless, what is it good for?
> 
> It's sometimes useful in cases where the target CPU doesn't have any better
> option (Speedstep/Powernow).  The big misconception is that it
> somehow saves power & increases battery life. Not so.
> All it does is 'not do work so often'.  The upside of this is
> that in some situations, we generate less heat this way.

This is perplexing. Less heat equals less power usage according to the
laws of thermodynamics.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Status of X86_P4_CLOCKMOD?

[Dave Jones]

On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
 > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
 > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
 > > 
 > >  > > > >  config X86_P4_CLOCKMOD
 > >  > > > > 	depends on EMBEDDED
 > >  > > > 
 > >  > > > This one is an x86_64 only issue, and yes, it's wrong.
 > >  > > 
 > >  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
 > >  > > almost any energy savings it was "hidden" under embedded.
 > >  > 
 > >  > But the EMBEDDED dependency is only on x86_64:
 > >  > 
 > >  > arch/i386/kernel/cpu/cpufreq/Kconfig:
 > >  > config X86_P4_CLOCKMOD
 > >  >         tristate "Intel Pentium 4 clock modulation"
 > >  >         select CPU_FREQ_TABLE
 > >  >         help
 > >  > 
 > >  > arch/x86_64/kernel/cpufreq/Kconfig:
 > >  > config X86_P4_CLOCKMOD
 > >  >         tristate "Intel Pentium 4 clock modulation"
 > >  >         depends on EMBEDDED
 > >  >         help
 > >  > 
 > >  > And if the option is mostly useless, what is it good for?
 > > 
 > > It's sometimes useful in cases where the target CPU doesn't have any better
 > > option (Speedstep/Powernow).  The big misconception is that it
 > > somehow saves power & increases battery life. Not so.
 > > All it does is 'not do work so often'.  The upside of this is
 > > that in some situations, we generate less heat this way.
 > 
 > This is perplexing. Less heat equals less power usage according to the
 > laws of thermodynamics.

you end up taking longer to do the same amount of work, so you
end up using the same overall power.

		Dave

Re: Status of X86_P4_CLOCKMOD?

[Dmitry Torokhov]

On 2/28/06, Dave Jones <davej@redhat.com> wrote:
> On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
>  >
>  > This is perplexing. Less heat equals less power usage according to the
>  > laws of thermodynamics.
>
> you end up taking longer to do the same amount of work, so you
> end up using the same overall power.
>

I'd say that energy usage is the same _per unit of work_. But if you
compare a box that is sitting idle 90% of the time at 0% throttling
vs. a box that is sitting idle 80% of the time with 50% throttling and
neither of these boxes support C2 you'll find that the second box uses
less energy overall.

--
Dmitry

Re: Status of X86_P4_CLOCKMOD?

[Matt Mackall]

On Tue, Feb 28, 2006 at 03:09:16PM -0500, Dave Jones wrote:
> On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
>  > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
>  > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
>  > > 
>  > >  > > > >  config X86_P4_CLOCKMOD
>  > >  > > > > 	depends on EMBEDDED
>  > >  > > > 
>  > >  > > > This one is an x86_64 only issue, and yes, it's wrong.
>  > >  > > 
>  > >  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
>  > >  > > almost any energy savings it was "hidden" under embedded.
>  > >  > 
>  > >  > But the EMBEDDED dependency is only on x86_64:
>  > >  > 
>  > >  > arch/i386/kernel/cpu/cpufreq/Kconfig:
>  > >  > config X86_P4_CLOCKMOD
>  > >  >         tristate "Intel Pentium 4 clock modulation"
>  > >  >         select CPU_FREQ_TABLE
>  > >  >         help
>  > >  > 
>  > >  > arch/x86_64/kernel/cpufreq/Kconfig:
>  > >  > config X86_P4_CLOCKMOD
>  > >  >         tristate "Intel Pentium 4 clock modulation"
>  > >  >         depends on EMBEDDED
>  > >  >         help
>  > >  > 
>  > >  > And if the option is mostly useless, what is it good for?
>  > > 
>  > > It's sometimes useful in cases where the target CPU doesn't have any better
>  > > option (Speedstep/Powernow).  The big misconception is that it
>  > > somehow saves power & increases battery life. Not so.
>  > > All it does is 'not do work so often'.  The upside of this is
>  > > that in some situations, we generate less heat this way.
>  > 
>  > This is perplexing. Less heat equals less power usage according to the
>  > laws of thermodynamics.
> 
> you end up taking longer to do the same amount of work, so you
> end up using the same overall power.

Doesn't make sense.

Power is energy consumption per unit time. Heat is energy dissipated
per unit time (both are measured in watts). So if you're saying "we
use the same amount of power", then conservation of energy implies "we
generate the same amount of heat." If you're instead saying "we use
the same amount of energy over a longer span of time", that means "we
draw less power from the battery" which means "battery lasts longer".

In short, power usage and heat production are _the same thing_.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Status of X86_P4_CLOCKMOD?

[Dominik Brodowski]

On Tue, Feb 28, 2006 at 02:47:20PM -0600, Matt Mackall wrote:
> On Tue, Feb 28, 2006 at 03:09:16PM -0500, Dave Jones wrote:
> > On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
> >  > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
> >  > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> >  > > 
> >  > >  > > > >  config X86_P4_CLOCKMOD
> >  > >  > > > > 	depends on EMBEDDED
> >  > >  > > > 
> >  > >  > > > This one is an x86_64 only issue, and yes, it's wrong.
> >  > >  > > 
> >  > >  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
> >  > >  > > almost any energy savings it was "hidden" under embedded.
> >  > >  > 
> >  > >  > But the EMBEDDED dependency is only on x86_64:
> >  > >  > 
> >  > >  > arch/i386/kernel/cpu/cpufreq/Kconfig:
> >  > >  > config X86_P4_CLOCKMOD
> >  > >  >         tristate "Intel Pentium 4 clock modulation"
> >  > >  >         select CPU_FREQ_TABLE
> >  > >  >         help
> >  > >  > 
> >  > >  > arch/x86_64/kernel/cpufreq/Kconfig:
> >  > >  > config X86_P4_CLOCKMOD
> >  > >  >         tristate "Intel Pentium 4 clock modulation"
> >  > >  >         depends on EMBEDDED
> >  > >  >         help
> >  > >  > 
> >  > >  > And if the option is mostly useless, what is it good for?
> >  > > 
> >  > > It's sometimes useful in cases where the target CPU doesn't have any better
> >  > > option (Speedstep/Powernow).  The big misconception is that it
> >  > > somehow saves power & increases battery life. Not so.
> >  > > All it does is 'not do work so often'.  The upside of this is
> >  > > that in some situations, we generate less heat this way.
> >  > 
> >  > This is perplexing. Less heat equals less power usage according to the
> >  > laws of thermodynamics.
> > 
> > you end up taking longer to do the same amount of work, so you
> > end up using the same overall power.
> 
> Doesn't make sense.
> 
> Power is energy consumption per unit time. Heat is energy dissipated
> per unit time (both are measured in watts). So if you're saying "we
> use the same amount of power", then conservation of energy implies "we
> generate the same amount of heat." If you're instead saying "we use
> the same amount of energy over a longer span of time", that means "we
> draw less power from the battery" which means "battery lasts longer".

So even if the battery lasts longer, you don't have anything of it, 'cause
the CPU can even compute _less_ in this longer time-span. Remember that
idling doesn't count...

> In short, power usage and heat production are _the same thing_.

Yes and no. The heat production is more levelled if you use throttling, so
the temperature achieved is lesser, which might cause fans not having to
start or air conditioning having less work to do.

	Dominik

Re: Status of X86_P4_CLOCKMOD?

[Matt Mackall]

On Tue, Feb 28, 2006 at 09:57:58PM +0100, Dominik Brodowski wrote:
> On Tue, Feb 28, 2006 at 02:47:20PM -0600, Matt Mackall wrote:
> > On Tue, Feb 28, 2006 at 03:09:16PM -0500, Dave Jones wrote:
> > > On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
> > >  > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
> > >  > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> > >  > > 
> > >  > >  > > > >  config X86_P4_CLOCKMOD
> > >  > >  > > > > 	depends on EMBEDDED
> > >  > >  > > > 
> > >  > >  > > > This one is an x86_64 only issue, and yes, it's wrong.
> > >  > >  > > 
> > >  > >  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
> > >  > >  > > almost any energy savings it was "hidden" under embedded.
> > >  > >  > 
> > >  > >  > But the EMBEDDED dependency is only on x86_64:
> > >  > >  > 
> > >  > >  > arch/i386/kernel/cpu/cpufreq/Kconfig:
> > >  > >  > config X86_P4_CLOCKMOD
> > >  > >  >         tristate "Intel Pentium 4 clock modulation"
> > >  > >  >         select CPU_FREQ_TABLE
> > >  > >  >         help
> > >  > >  > 
> > >  > >  > arch/x86_64/kernel/cpufreq/Kconfig:
> > >  > >  > config X86_P4_CLOCKMOD
> > >  > >  >         tristate "Intel Pentium 4 clock modulation"
> > >  > >  >         depends on EMBEDDED
> > >  > >  >         help
> > >  > >  > 
> > >  > >  > And if the option is mostly useless, what is it good for?
> > >  > > 
> > >  > > It's sometimes useful in cases where the target CPU doesn't have any better
> > >  > > option (Speedstep/Powernow).  The big misconception is that it
> > >  > > somehow saves power & increases battery life. Not so.
> > >  > > All it does is 'not do work so often'.  The upside of this is
> > >  > > that in some situations, we generate less heat this way.
> > >  > 
> > >  > This is perplexing. Less heat equals less power usage according to the
> > >  > laws of thermodynamics.
> > > 
> > > you end up taking longer to do the same amount of work, so you
> > > end up using the same overall power.
> > 
> > Doesn't make sense.
> > 
> > Power is energy consumption per unit time. Heat is energy dissipated
> > per unit time (both are measured in watts). So if you're saying "we
> > use the same amount of power", then conservation of energy implies "we
> > generate the same amount of heat." If you're instead saying "we use
> > the same amount of energy over a longer span of time", that means "we
> > draw less power from the battery" which means "battery lasts longer".
> 
> So even if the battery lasts longer, you don't have anything of it, 'cause
> the CPU can even compute _less_ in this longer time-span. Remember that
> idling doesn't count...

Which is different from other power-saving modes how? If it means I
can read my email longer on the plane, it's a power-saving mode.
 
> > In short, power usage and heat production are _the same thing_.
> 
> Yes and no. The heat production is more levelled if you use throttling, so
> the temperature achieved is lesser, which might cause fans not having to
> start or air conditioning having less work to do.

The time scale for heat propagation is enough slower than throttling
that I'd expect this difference to amount to approximately nil. It
takes many seconds for heat to propagate from a core to a thermal
sensor inside a laptop, and the intervening material (silicon,
ceramic, plastic, aluminum, air) acts as a low-pass filter so usage
spikes on sub-second scales are simply not visible. In other words,
the temperature will be the same for the same energy consumption
averaged over the time it takes for the heat to propagate.

And the time for a usage spike to be visible to a server room air
conditioner is probably closer to a ten minute time frame.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Status of X86_P4_CLOCKMOD?

[Dominik Brodowski]

On Tue, Feb 28, 2006 at 03:26:32PM -0600, Matt Mackall wrote:
> > So even if the battery lasts longer, you don't have anything of it, 'cause
> > the CPU can even compute _less_ in this longer time-span. Remember that
> > idling doesn't count...
> 
> Which is different from other power-saving modes how? If it means I
> can read my email longer on the plane, it's a power-saving mode.

But you can't... [*]

> > > In short, power usage and heat production are _the same thing_.
> > 
> > Yes and no. The heat production is more levelled if you use throttling, so
> > the temperature achieved is lesser, which might cause fans not having to
> > start or air conditioning having less work to do.
> 
> The time scale for heat propagation is enough slower than throttling
> that I'd expect this difference to amount to approximately nil.

For short-term load spikes, yes. If your server has a task which takes up
one hour at full time, and the temp reaches 45° C then, but you have nothing
else for it to do overnight, then it does might sense to throttle it to
50%, which will mean two hours, but only 40° C.

	Dominik


[*] unless the idling algorithm is broken and does not enter C2-type idle
states.

Re: Status of X86_P4_CLOCKMOD?

[Dmitry Torokhov]

On 2/28/06, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> On Tue, Feb 28, 2006 at 03:26:32PM -0600, Matt Mackall wrote:
> > > So even if the battery lasts longer, you don't have anything of it, 'cause
> > > the CPU can even compute _less_ in this longer time-span. Remember that
> > > idling doesn't count...
> >
> > Which is different from other power-saving modes how? If it means I
> > can read my email longer on the plane, it's a power-saving mode.
>
> But you can't... [*]
...
> [*] unless the idling algorithm is broken and does not enter C2-type idle
> states.

Or box does not support anything but C1.

--
Dmitry

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Tuesday 28 February 2006 22:39, Dmitry Torokhov wrote:
> On 2/28/06, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> > On Tue, Feb 28, 2006 at 03:26:32PM -0600, Matt Mackall wrote:
> > > > So even if the battery lasts longer, you don't have anything of it, 'cause
> > > > the CPU can even compute _less_ in this longer time-span. Remember that
> > > > idling doesn't count...
> > >
> > > Which is different from other power-saving modes how? If it means I
> > > can read my email longer on the plane, it's a power-saving mode.
> >
> > But you can't... [*]
> ...
> > [*] unless the idling algorithm is broken and does not enter C2-type idle
> > states.
> 
> Or box does not support anything but C1.

There are quite advanced forms of C1 around.
And I would expect even old style dumb C1 to save more than throttling.

-Andi