Comparative performance: Applications performing streaming multimedia require service quality that's predictable, configurable, and managed on an end-to-end basis—from origination application to destination application through intervening I/O buffers, devices, operating-system tasks, protocol stacks, and across network flows. This service quality is an amalgamation of subjective and objective measures, such as round-trip latency, jitter in latency, bandwidth, stream synchronization, frame size, color depth, compression, image artifacts, sound quality, and so forth.
Measuring QoS: The subjectivity of QoS makes its objective measurement difficult. For audio, the traditional approach has been to survey an audience of listeners and compile a Mean Opinion Score (MOS) of the audio quality. Recently, computer techniques have begun to appear: the Perceptual Speech Quality Measurement System (PSQM) and Perceptual Analysis/Measurement System (PAMS) are now in wide use. These use carefully selected speech samples as inputs. They then use signal processing on the outputs to compare the received signal with the original sample and generate a comparative MOS value.
A subjective technique, im-plemented here, is simply to listen to the audio playback, as the human ear is a very sensitive detector of poor quality. The reserved utilization can be tuned down until the ear de-tects stuttering in the audio playback. It's then nudged back up, so no stuttering occurs. Likewise, for assessing video quality, a similar technique of looking for pauses, blurring, and lost lip synchronization is used to determine when the video player lacks resources.
Test configuration: Multiple players could be run simultaneously to determine how many of these players can operate at the same time without affecting the quality of their peers. Unfortunately, it turns out that the Advanced Linux Sound Architecture (ALSA) or Open Sound System (OSS) sound drivers in Linux use one or more semaphores to provide mutually exclusive access to the sound hardware.
Although it's quite reasonable, this prevents one from running multiple players. (Windows, by the way, makes no such restrictions, and one can start up a true cacophony of audio players.) Therefore, the approach taken is to run a single player in competition with heavy processor loading, and to determine the player's ability to maintain QoS in spite of the competition.
Player performance without reservations: A processor reservation that assigns a specific portion of the processor to an infinite-shell loop is first created. This creates a well-defined load that will demonstrate the effectiveness of the player reservations—by competing against the multimedia player while it operates. This reservation is increased until the quality of the unreserved player becomes noticeably impacted.
The RealPlayer and the X server, when unreserved, are able to withstand a constant, competitive load of about 5%—a loss of 500 µs in each 10-ms period. Beyond this, RealPlayer begins to drop frames, and X begins to stutter-paint the requested frames. Therefore, the competing reservation is created with parameters:
{resource=CPU, T=10 ms, C=500 us, D=10 ms, depletion=HARD, inherit=TRUE}
As the competitive load is increased, either by increasing the reservation or by adding additional unreserved tasks to the workstation, the quality of the presentation continues to deteriorate. More and more frames are dropped, X repaints begin to stutter, and eventually even audio becomes affected.
Player performance with reservations: To assure that the players are competing against the same environment as experienced by the unreserved players, the infinite-shell-loop reservation is recreated. It's given the maximum amount it had in the unreserved case, or the amount of processor remaining after assuring the players their minimum reservations. In this case, the same 5% reservation can be granted to the competitive load.
RealPlayer requires approximately 65% of the processor, i.e., 6.5 ms per each 10-ms period, and a corresponding X server reservation for 30% of the processor, or 3 ms per each 10-ms period. This is required to play the video clip without stuttering frames and to achieve proper lip synchronization. It can be readily provided by using the rkexec script to create a reservation with parameters:
{resource=CPU, T=10 ms, C=6.5 ms, D=10 ms, depletion=HARD, inherit=TRUE}
for RealPlayer, and a reservation for X with parameters:
{resource=CPU, T=10 ms, C=3 ms, D=10 ms, depletion=HARD, inherit=TRUE}
Having been given these reservations, the RealPlayer player is, for all practical purposes, immune to other activity on the desktop. Additional unreserved tasks on the workstation compete for the scarce remaining resources. Still, the presentation maintains its quality. (With 95% of the processor dedicated to the RealPlayer presentation, little remains for anything else. But one can actually squeeze quite a bit from 5% of a 662-MHz machine running Linux.)
Simple deployment for applications: Because the resource reservations can be created externally to applications and can have tasks dynamically attached to these reservations, employing reservations for the majority of systems today is relatively easy. No code modifications are necessary, and the reservations can be set up through shell scripts and managed via applets.
For those applications that need more direct control of scheduling primitives in general and reservations in particular, an API and a system-call library are available to enable resource reservation operations to be performed directly from application code.
The ability to provide this QoS assurance is unique to the Linux/RT operating system. Details on this operating system and APIs for its Resource Kernel are available in online documentation at www.timesys.com.
Doug Locke is vice president of engineering for TimeSys Corp., Pittsburgh, Pa. He received his PhD from Carnegie Mellon University, Pittsburgh. Contact him by phone at (412) 681-6899, ext. 233, or via e-mail at doug.locke@timesys.com.
Lonnie VanZandt was a senior systems engineer at TimeSys Corp. when this article was written. He holds a BSCE and an MSCE from the University of Illinois, Urbana.