I/O time, unlike CPU time, is unaffected by changes in CPU speed. The model from which PACE arises accounts only for task CPU time, so PACE does not give optimal results when I/O can occur. Essentially, the occurrence of I/O will delay the completion of a task, possibly causing it to miss its deadline.
We deal with this in the following way. Since the problem is to complete the CPU work and the I/O by the deadline, we must complete the CPU work within a period equal to the deadline minus the I/O time. If we knew I/O time in advance, PACE could compute the optimal schedule merely by substituting the deadline minus I/O time for the deadline. Since we do not know I/O time in advance, we initially assume it is 0. If I/O occurs later, we determine how long it took and accelerate the schedule to make up for the lost time.
Theoretically, accelerating the schedule properly requires performing
a new complex calculation using the PACE formula. However, we can use
a shortcut: we multiply all speeds in the schedule by a constant
factor, where we choose that factor such that after rounding all
resulting speeds to the nearest worthwhile speed we get a schedule
that meets the new deadline constraint. The argument why this works
is as follows: The distribution of task work remaining has by
assumption not changed, but the deadline has effectively gotten
shorter. Thus, all that has changed is the optimal value of 
.
This means the ratio of the new optimal speed to the old optimal speed
is roughly the same for all points in the schedule, assuming that the
function of energy versus speed has a reasonable shape.