Hmmm...I don't think the answer is so clear. I actually measured a machine
about two years back, and my results showed that T-states apparently do save
energy, just as P-states do (at least on the CPU I measured).
I've enclosed the results (open office format). This was on an Acer
3400 Ferrari laptop (mobile AMD Athlon 64 3000+ processor), measured with
a Kill-a-Watt power meter.
The chart at the top is how much power is consumed. You can see that
throttling definitely improved power consumption on this laptop, although
as was already pointed out, P-states have a greater effect.
By the way, the chart at the bottom, which was what I was really interested in,
was
attempting to answer this question:
Does it save money to run at lower power states (for a longer
period of time), or would it be cheaper to run at the higher power
state (for a shorter period of time)?
The answer, for this particular machine, was "it's cheaper to run your
compute-intensive app at a high power P-state for a shorter period of time".
Mike
Li, Aubrey wrote:
> On Tuesday, October 30, 2007 5:02 AM, tesla-dev-bounces at opensolaris.org
> wrote:
>
>> Eric Saxe wrote:
>>> Yea, it's a good question. My impression of the T-states, is that in
>>> the general (common) case the system wouldn't use them, since from my
>>> understanding their purpose is mainly as a mechanism for quickly (and
>>> forcibly) throttling the processor clock to bring a thermal situation
>>> under control.
>> Let's think about that. T-states represent nothing more than the
>> ability to hold the CPU for some percentage of clock cycles.
>> T-states do not
>> reduce the CPU
>> clock
>> and do not reduce the voltage to the CPU.
>
> Yes, T-states just forcefully introduce idle cycles in the processor,
> and these idle cycles don't
> get into power saving C-states.
>
>> Given a choice between a T-state that halts the CPU for 50% of
>> the clock
>> cycles
>> and a P-state which runs the CPU at 50% of full-speed, the
>> P-state will
>> win in
>> terms of power savings (and thermal safety) every time. Given
>> that the
>> thermal
>> time-constant of a CPU is *much* greater than the time it takes to
>> switch P-states, I don't think there's a compelling case for T-state
>> usage *when P-states are supported*.
>> T-states give a linear power reduction, while P-states give a
>> geometric power
>> reduction.
>
> That's not ture, T-state doesn't save any energy.
>
>> While T-state switching is of much lower latency, it is no
>> more forcible
>> than
>> switch P-states.
>>
>> Where I can see T-states being useful is on systems where there's no
>> P-state support, or to create intermediate levels between P-states.
>
> T-states is only used when processor is over heat.
> It's not designed for normal power saving.
> We should avoid T-state whenever we can.
>
>>> It's also my understanding that the performance impact of
>>> the T-states are fairly severe, which begs the question if we would
>>> ever want the CPU to enter them when not idle. When the CPU is idle,
>>> I would wonder how T-states would compare to what we get from
>>> entering the C1 state. Since T-states don't change the voltage, I
>>> would guess that C1 would actually buy more. Maybe Aubrey or someone
>>> else can correct me if I'm mistaken...
>> I don't believe it makes sense to compare T-states to C-states - I'd
>> compare T-states to P-states. The performance impact of a T-state is
>> comparable
>> to that of
>> a P-state which
>> runs at the same effective clock rate, while the power savings of a
>> P-state is greater.
>
> That doesn't make sense to me, too. They are not comparable. Because
> they are in different cases.
>
>>> Aren't there also cases where the processor could go into a T-state
>>> without the OS actually knowing?
>> It's certainly possible that the chipset could start holding the CPU
>> halted for some percentage of clock cycles, I suppose.
>>
>
> The answer is yes, cpu has a thermal sensor, and it can automatically
> throttle in overheat case.
>
> Thanks,
> -Aubrey
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: efficiency of throttling vs P state 2.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 24359 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20071030/86d6cd53/attachment.ods>
