Check out the new USENIX Web site. next up previous
Next: Implementing the Scheduling Algorithms Up: Methodology Previous: Measuring Power and Total


Workload

We used a varied workload to assess the performance of the different clock scaling algorithms. Since it's not clear what applications will be common on pocket computers, we used some obvious applications (web browsing, text reading) and other less obvious applications (chess, mpeg video and audio). The applications ran either directly on top of the Linux operating system or within a Java virtual machine [14]. To capture repeatable behavior for the interactive applications, we used a tracing mechanism that recorded timestamped input events and then allowed us to replay those events with millisecond accuracy. We did not trace the mpeg playback because there is no user interaction, and we found little inter-run variance. We used the following applications:

MPEG:
We played a 320x200 color MPEG-1 video and audio clip at 15 frames a second. The mpeg video was rendered as a greyscale image on the Itsy. Audio was rendered by sending the audio stream as a WAV file to an audio player which ran as a separate process, forked from the video player. There is no explicit synchronization between the audio and video sequences, but both are sequenced to remain synchronized at 15 frames/second. The clip is 14 seconds and was played in a loop to provide 60 seconds of playback.

Web:
We used a Javabean version of the IceWeb browser to view content stored on the itsy. We selected a file containing a stored article from www.news.com concerning the Itsy. We scrolled down the page, reading the full article. We then went back to the root menu and opened a file containing an HTML version of WRL technical report TN-56, which has many tables describing characteristics of power usage in Itsy components. The overall trace was 190 seconds of activity.

Chess:
We used a Java interface to version 16.10 of the Crafty chess playing program. Crafty was run as a separate process. Crafty uses a play book for opening moves and then plays for specific periods of time in later stages of the games and plays the best move available when time expires. The 218 second trace includes a complete game of Crafty playing against a novice player (who lost, badly).

TalkingEditor:
We used a version of the ``mpedit'' Java text editor that had been modified to read text files aloud using the DECtalk speech synthesis system (which is run in a separate process). The input trace records the user selecting a file to be opened using the file dialogue, (i.e. moving to the directory of the short text file and selecting the file), then having it spoken aloud and finally opening and having another text file read aloud. The trace took 70 seconds.

The Kaffe Java system [14] uses a JIT, makes extensive use of dynamic shared libraries and supports a threading model using setjmp/longjmp. The graphics library used by Java is a modified version of the publically available GRX graphics library and uses a polling I/O model to check for new input every 30 milliseconds. The MPEG player renders directly to the display.


next up previous
Next: Implementing the Scheduling Algorithms Up: Methodology Previous: Measuring Power and Total
NEUFELD 2000-09-12