Check out the new USENIX Web site. next up previous
Next: Time to perform PACE Up: Results Previous: Time to perform RightSpeed


Effect on performance

Applications can specify performance targets for tasks. However, since Windows 2000 is not a real-time operating system, scheduling decisions do not necessarily happen precisely when they should, so RightSpeed will not necessarily meet these targets. In this subsection, we evaluate how closely it does.

These evaluations require workloads. We derived these workloads from traces of users performing their normal business on desktop machines running Windows NT or Windows 2000. For more details on the tracing, see [10]. Each workload corresponds to all tasks requiring no I/O that were triggered by keystroke and mouse click events delivered to a particular application for a particular user during the several months that user was traced. Table 4 gives a brief description of each workload; for more details about the users and applications, see [12] and [11]. We inferred when tasks began and ended using the method from [12].


Table 4: Traced application workloads we use in certain simulations
Workload User Application Key Click
events events
1 1 explorer 17,105 9,549
2 2 explorer 27,972 19,866
3 3 explorer 9,905 2,617
4 4 explorer 11,276 6,301
5 5 explorer 21,297 9,291
6 6 explorer 6,096 5,381
7 7 explorer 6,938 4,443
8 8 explorer 24,208 9,337
9 1 netscape 797,642 22,512
10 2 iexplore 193,823 59,667
11 3 psp 64,229 3,320
12 4 outlook 359,839 14,984
13 5 outlook 109,202 2,633
14 6 grpwise 275,972 13,576
15 7 winword 50,799 2,766
16 8 excel 13,891 2,016


Our traces do not give us sufficient information to precisely recreate the workloads. For instance, we do not collect disk contents and we irreversibly encrypt alphanumeric keystrokes. To simulate RightSpeed, however, we need only know when and for how long each task ran. Thus, we use a simulator that simulates each task by performing additions repeatedly in a tight loop for the same number of cycles as the original task took. Our workload simulator indicates the beginning of each task to RightSpeed with an explicit RSLib call; it sleeps for 2 ms at the end of each task to let RightSpeed automatically detect the end of the task. We run this workload simulator on the AMD machine to measure the performance obtained when RightSpeed schedules the speeds.

We evaluate RightSpeed's performance as follows. We assign performance targets corresponding to an average pre-deadline speed of 630 MHz for keystroke tasks and 765 MHz for mouse click tasks. For each workload, we calculate how many deadlines it theoretically should miss and how much total delay past deadlines it should achieve. We then simulate RightSpeed to see how many deadlines it actually misses and the total delay it actually achieves.

We find that RightSpeed misses 1.5% fewer to 0.3% more deadlines than the target, with an average absolute error of 0.4%. It has delay from 0.5% less to 0.1% more than the target with an average absolute error of 0.2%. Since RightSpeed conservatively rounds speeds for intervals to maximize the probability of making deadlines, it is not surprising that it tends to miss fewer deadlines and have less delay than the target. Nevertheless, the absolute error is very low, showing that RightSpeed is effective at meeting performance targets even though it must use the millisecond-granularity timer of Windows 2000 and even though Windows 2000 makes no guarantees about when speed-changing routines will actually execute.


next up previous
Next: Time to perform PACE Up: Results Previous: Time to perform RightSpeed
Jay Lorch 2003-02-19