Requirements of Multimedia Kernels
Requirements of Multimedia Kernels
As a result of the characteristics described in Section 20.1.2, multimedia applications often require levels of service from the operating system that differ from the requirements of traditional applications, such as word processors, compilers, and spreadsheets.
Timing and rate requirements are perhaps the issues of foremost concern, as the playback of audio and video data demands that the data be delivered within a certain deadline and at a continuous, fixed rate. Traditional applications typically do not have such time and rate constraints.
Tasks that request data at constant intervals—or periods—are known as periodic processes. For example, an MPEG-1 video might require a rate of 30 frames per second during playback. Maintaining this rate requires that a frame be delivered approximately every 1/30"' or 3.34 hundredths of a second. To put this in the context of deadlines, let's assume that frame Fj succeeds frame F; in the video playback and that frame F, was displayed at time To.
The deadline for displaying frame Fj is 3.34 hundredths of a second after time To. If the operating system is unable to display the frame by this deadline, the frame will be omitted from the stream. As mentioned earlier, rate requirements and deadlines are known as quality of service (QoS) requirements. There are three QoS levels:
1. Best-effort service. The system makes a best-effort attempt to satisfy the requirements; however, no guarantees are made.
2. Soft QoS. This level treats different types of traffic in different ways, giving certain traffic streams higher priority than other streams. However, just as with best-effort service, no guarantees are made.
3. Hard QoS. The quality-of-service requirements are guaranteed. Traditional operating systems—the systems we have discussed in this text so far—typically provide only best-effort service and rely on overprovisioning; that is, they simply assume that the total amount of resources available will tend to be larger than a worst-case workload would demand.
If demand exceeds resource capacity, manual intervention must take place, and a process (or several processes) must be removed from the system. However next-generation multimedia systems cannot make such assumptions. These systems must provide continuous-media applications with the guarantees made possible by hard QoS.
Therefore, in the remainder of this discussion, when we refer to QoS, we mean hard QoS. Next, we explore various techniques that enable multimedia systems to provide such service-level guarantees. There are a number of parameters defining QoS for multimedia applications, including the following:
• Throughput. Throughput is the total amount of work done during a certain interval. For multimedia applications, throughput is the required data rate.
Delay. Delay refers to the elapsed time from when a request is first submitted to when the desired result is produced. For example, the time from when a client requests a media stream to when the stream is delivered is the delay. » Jitter. Jitter is related to delay; but whereas delay refers to the time a client must wait to receive a stream, jitter refers to delays that occur during playback of the stream. Certain multimedia applications, such as on-demand real-time streaming, can tolerate this sort of delay. Jitter is generally considered unacceptable for continuous-media applications, however, because it may mean long pauses—or lost frames—during playback. Clients can often compensate for jitter by buffering a certain amount of data—say, 5 seconds' worth—before beginning playback.
• Reliability. Reliability refers to how errors are handled during transmission and processing of continuous media. Errors may occur due to lost packets in the network or processing delays by the CPU. In these—and other—scenarios, errors cannot be corrected, since packets typically arrive too late to be useful.
The quality of service may be negotiated between the client and the server. For example, continuous-media data may be compressed at different levels of quality: the higher the quality, the higher the required data rate.
A client may negotiate a specific data rate with a server, thus agreeing to a certain level of quality during playback. Furthermore, many media players allow the client to configure the player according to the speed of the client's connection to the network. This allows a client to receive a streaming service at a data rate specific to a particular connection. Thus, the client is negotiating quality of service with the content provider. To provide QoS guarantees, operating systems often use admission control, which is simply the practice of admitting a reqtiest for service only if the server has sufficient resources to satisfy the request.
We see admission control quite often in our everyday lives. For example, a movie theater only admits as many customers as it has seats in the theater. (There are also many situations in everyday life where admission control is not practiced but would be desirable!) If no admission control policy is used in a multimedia environment, the demands on the system might become so great that the system becomes unable to meet its QoS guarantees. In Chapter 6, we discussed using semaphores as a method of implementing a simple admission control policy.
In this scenario, there exist a finite number of non-shareable resources. When a resource is requested, we will only grant the request if there are sufficient resources available; otherwise the requesting process is forced to wait until a resource becomes available. Semaphores may be used to implement an admission control policy by first initializing a semaphore to the number of resources available. Every request for a resource is made through a waitO operation on the semaphore; a resource is released with an invocation of signal 0 on the semaphore.
Once all resources are in use, subsequent calls to wait () block until there is a corresponding signal 0 . A common technique for implementing admission control is to use resource reservations. For example, resources on a file server may include the CPU, memory, file system, devices, and network (Figure 20.1). Note that resources may be either exclusive or shared and that there may be either single or multiple instances of each resource type. To use a resource, a client must make a reservation request for the resource in advance. If the request cannot be granted, the reservation is denied. An admission control scheme assigns a resource manager to each type of resource.
Requests for resources have associated QoS requirements—for example, required data rates. When a request for a resource arrives, the resource manager determines if the resource can meet the QoS demands of the request. If not, the request may be rejected, or a lower level of QoS may be negotiated between the client and the server. If the request is accepted, the resource manager reserves the resources for the requesting client, thus assuring the client the desired QoS requirements. In Section 20.7.2, we examine the admission control algorithm used to ensure QoS guarantees in the CineBlitz multimedia storage server.
Frequently Asked Questions
- Operating System Concepts ( Multi tasking, multi programming, multi-user, Multi-threading )
- Different Types of Operating Systems
- Batch Operating Systems
- Time sharing operating systems
- Distributed Operating Systems
- Network Operating System
- Real Time operating System
- Various Operating system services
- Architectures of Operating System
- Monolithic architecture - operating system
- Layered Architecture of Operating System
- Microkernel Architecture of operating system
- Hybrid Architecture of Operating System
- System Programs and Calls
- Process Management - Process concept