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: Implementing the Scheduling Algorithms
Up: Methodology
Previous: Measuring Power and Total
NEUFELD
2000-09-12