Ah, yes -- you're right.
I went back and calculated the total power cost over N minutes, assuming
a 1-minute CPU task, and in all cases, although a throttled CPU *does*
consume less power, the task overall takes longer to complete -- a factor
which always (for this machine) outweighs the power savings of throttling
itself.
So, on balance, it does seem that it is less costly to run at the lowest P-state
consistent with desired latency/throughput, and to never throttle (even though
throttling does reduce power consumption).
Cost in Watt-sec for a 1 minute CPU task in a 10-minute window
cost (W-sec) throttle
P-state 100 75 50 25 0
-------------------------------------------
P0 -- 403 383 376 373
P1 -- 385 372 368 366
P2 -- 378 369 365 364
P3 -- 359 359 359 359
Results are similar for N other than 10.
Mike
Mark Haywood wrote:
> Michael Pogue wrote:
>> Hmmm...I believe that T-states will still always save power, though,
>> while the CPU is executing instructions. If the slowdown is acceptable,
>> I'm not sure why this method would not be a useful way to consume
>> less power.
>>
>> Here's an example, based on the data I sent earlier:
>>
>> Let's say we have a task that takes 1 CPU minute of time (at full power,
>> no throttle), and we need to execute it once every 10 minutes. Look at
>> the second table -- the largest entry under 10 minutes is 8.44
>> minutes (P3/75% throttle).
>>
>> So, if we ran that box at P3/75% for 8.44 minutes, and P3/100% (C1,
>> essentially) total power consumption would be about:
>>
>> 36.25*8.5 + 34*1.5 = 359 W-min.
>>
>> That's a better choice (about 4% better) than running P0/0% for 1 minute
>> and P3/100%(C1) for 9 minutes, which would consume about:
>>
>> 67*1 + 34*9 = 373 W-min.
>>
>> Based on these measurements, at least, it seems to me that for a given
>> P-state, throttling could always save *some* power on this machine (as long
>> as we're still OK with the additional slowdown, which has to be the case
>> for any power/frequency manipulation, as Dana implied).
>>
>> Does this meet the definition of "same amount of work in the same amount
>> of time, while consuming less energy"? I think it does. :-)
> Yes, but I believe that you could run have the job at P3/0% for 2.11
> minutes and then P3/100%(C1) for 7.89 minutes:
>
> 43*2.11 + 34*7.89 = 359 W-min
>
> In other words, it was P3 that got the work done while consuming less
> power. All throttling did for you was increase the amount of time to get
> the work done, right?
>
> Mark
>
>> Mike
>>
>> Andrei Dorofeev wrote:
>>> On 10/30/07, Dana H. Myers <Dana.Myers at sun.com> wrote:
>>>>> I would agree with Aubrey that T-states don't save power if by "save" we
>>>>> mean that we can do the same amount of work at the same amount of time
>>>>> while consuming less energy.
>>>> I don't think P-states meet this definition of saving power, either, do
>>>> they?
>>> Actually, I think P-states can be (at least theoretically) used in such a
>>> way
>>> that this definition is met. In an ideal environment where we know
>>> precisely
>>> what are the requirements in terms of CPU cycles of a given workload, we
>>> can afford putting CPU into lower FID/VID without loosing performance and
>>> increasing run times while saving power. Attempting to do the same thing
>>> with T-states will not save any power because we're going to stay in C1 with
>>> or without T-states. Also, just spending C1 time in lowest P-state alone
>>> can save power on AMD CPUs which don't automatically drop
>>> frequencies/voltages upon entering C1 (which is what C1E on Intel CPUs is
>>> for).
>>>
>>> - Andrei
>>> _______________________________________________
>>> tesla-dev mailing list
>>> tesla-dev at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>> _______________________________________________
>> tesla-dev mailing list
>> tesla-dev at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
