We are omitting a detailed exposition on the scheduling behavior of
each scheduling policy primarily because most of them resulted in
equivalent (and poor) behavior. Recall that the best possible
scheduling goal for MPEG would be to switch to a 132MHz speed and
continue to render all the frames at that speed. No heuristic
policy that we examined achieved this
goal. Figure 8 shows the clock setting
behavior of the best policy we found. That policy uses the PAST
heuristic (i.e.
) and ``pegs'' the CPU speed either to
206MHz or 59MHz depending on the weight metric. The bounds on the
hysteresis where that a CPU utilization greater than 98% would cause
the CPU to increase the clock speed and a CPU utilization less than
93% would decrease the clock speed.
This policy is ``best'' because it never misses any deadline (across all the applications) and it also saves a small but significant amount of energy. This last point is illustrated in Table 2. This table shows the 95% confidence interval for the average energy needed to run the MPEG application. The reduction in energy between 206MHz and 132MHz occurs because the application wastes fewer cycles in the application idle loop used to meet the frame delays for the MPEG clip. A roughly 8% energy reduction occurs when we drop the processor voltage to 1.23V - this is less than the 15% maximum reduction we measured because the application uses resources (e.g. audio) that are not affected by voltage scaling.
|
The PAST policy we described results in a small but statistically significant reduction in energy for the MPEG application. Allowing the processor to scale the voltage when the clock speed drops below 162.2MHz results in no statistical decrease.
We initially surmised that there is no improvement because the cost of voltage and clock scaling on our platform out-weighs any gains. We measured the cost of clock and voltage scaling using the DAQ. To measure clock scaling, we coded a tight loop that switched the processor clock as quickly as possible. Before each clock change, we inverted the state of a specific GPIO and used the DAQ to measure the interval with high precision. We took measurements when the clock changed across many different clock settings ( e.g. from 59 to 206MHz, from 191 to 206MHz and so on).
Clock scaling took approximately 200microseconds, independent of the starting or target speed. During that time, the processor can not execute instructions. Thus, frequency changing varies between 11,200 clock periods at 59MHz and 40,000 clock periods at 200MHz.
We measured the time for the voltage to settle following a voltage change. It takes roughly 250 microseconds to reduce voltage from 1.5V to 1.23V; in fact, the voltage slowly reduces, drops below 1.23V and then rapidly settles on 1.23V. Voltage increases were effectively instantaneous. We suspect the slow decay occurs because of capacitance; many processors use external decoupling capacitors to provide sufficient current sourcing for processors that have widely varying current demands.
These measurements indicate that the time needed for clock and voltage changes are less than 2% of the scheduling interval; thus, we would be able to change the clock or voltage on every scheduling decision with less than 2% overhead. The fact that we see little energy reduction is related to the limited energy savings possible with the voltage scaling available on this platform and the efficacy of the policies we explored.