Resource Management To provide a certain QoS level to an - PowerPoint PPT Presentation

Resource Management To provide a certain QoS level to an application, not only does a system need to have sufficient resources, it also needs to make these resources available to an application when they are needed

Resource Scheduling ● A resource scheduler determines the priority of processes based on certain criteria ● Traditional resource schedulers base their priority assignments on responsiveness and fairness ● However, the existence of deadlines for the delivery of individual multimedia data elements changes the nature of the scheduling problem

Multimedia Challenge ● As multimedia systems have to handle both discrete and continuous media, it becomes a challenge to provide sufficient service to time-dependent streams without causing starvation of discrete-media access and other interactive applications ● Fair scheduling - in an attempt to prevent ill-behaved streams taking too much bandwidth, a common approach is to apply round-robin scheduling to all streams in the same “class” ● This is known as "fair queuing" ● Weighted fair queuing allows the individual streams within the class to be scheduled

Real-time Scheduling ● Several real-time algorithms have been developed ● Assuming that the CPU resources have not been over- allocated, they assign CPU time slots to a set of processes in a manner that ensures that they complete their tasks on time

Earliest-Deadline-First Scheduling ● Very popular when used with multimedia streams ● Uses a deadline that is associated with each of its work items to determine the next item to be processed ● The earliest deadline goes first ● EDF scheduling is optimal for allocating a single resource based on timing criteria

Rate-Monotonic Scheduling ● EDF requires one scheduling decision per message, which can be inefficient ● RM scheduling can be used for real-time scheduling of periodic processes (that is, more than one message is processed by each "scheduling decision") ● Streams are assigned priorities according to their rate; the higher the rate of work items on a stream, the higher the priority of a stream ● Variations on both EDF and RM exist

Stream Adaptation ● Whenever a certain QoS cannot be guaranteed, an application needs to adapt to changing QoS levels ● Any adjustments translate into different levels of media presentation quality ● If data is not dropped, then delay of a stream will increase over time ● Such a delay may or may not be tolerable, depending on the application in question

Some Example Adjustments ● The simplest form of adjustment is to drop pieces of information ● Easily done in audio streams (although can be very noticeable to listener) ● Motion JPEG (where each frame is freestanding) can tolerate dropped frames quite well ● MPEG (where the interpretation of a frame depends on the values of adjacent frames) is less tolerable to omissions - the encoding mechanism may in fact amplify errors of this type - whoops!

Scaling ● Scaling adapts a stream to the bandwidth available in the system before it enters a bottleneck resource in order to resolve contention ● Scaling is best applied when live streams are sampled ● Scaling may be too cumbersome if the entire stream has to be decompressed and encoded again just for scaling purposes ● Scaling algorithms are media-dependent, although the overall approach is to use a subsample of a given signal

Example Scaling Techniques ● Temporal scaling - reduces the resolution by decreasing the number of video frames transmitted within an interval (better for Motion JPEG than for MPEG streams) ● Spatial scaling - reduces the number of pixels of each image in the video stream (JPEG and MPEG-2 support spatial scaling) ● Frequency scaling - modifies the compression algorithm applied to an image ● Amplitudinal scaling - reduces the colour depths for each pixel ● Colour-space scaling - reduces the number of entries in the colour space

Scaling in Action ● Combinations of any of the scaling techniques are possible ● Scaling systems consist of a monitor process at the target and a scaler process at the source ● At the target, delayed messages are an indication of a bottleneck within the stream ● This results in a "scale-down" message from the target to the source, which triggers scaling ● After some time, the source removes the scaling (ramps back up with a “scale-up” message) ● Scaling oscillation can be a problem - scale-down, scale-up, scale-down, scale-up, and so on ...

Filtering ● As scaling modifies a stream at the source, it is not always suitable for applications that involve several receivers, as all targets receive the degraded stream ● Filtering is a method that provides the best possible QoS to each target by applying scaling not at the source but at each relevant node along a path from the source to the target ● Such a technique is supported in RSVP

Filtering Source Targets High bandwidth Medium bandwidth Low bandwidth

Tiger Case Study ● A video storage system that supplies multiple real-time video streams simultaneously is seen as an important consumer-oriented multimedia application ● One of the earliest (and most advanced) examples of such an application is Microsoft's Tiger Video Server, which was publicly unveiled by Microsoft Research Labs (MRL) in 1996

Tiger Design Goals ● Video-on-demand for a large number of end-users - speedy first play, pause, rewind, fast-forward, unsynchronized requests for the same movie resulting in many time-shifted playings of the same content ● QoS - video to be supplied at a constant rate, with small jitter bounds (determined by the client) and minimal loss rate ● Distributed Scalability - support for up to 10,000 clients (and beyond) ● Low-cost hardware - commodity PCs at both the server and client end-points ● Fault tolerant - the system should continue to operate after the failure if any single PC server or disk drive

Tiger Configuration Controller low-bandwidth network 2n+1 0 n+1 1 n+2 2 n+3 3 n+4 n Cub 0 Cub 1 Cub 2 Cub 3 Cub n high-bandwidth ATM switching network Start/Stop requests from clients video distribution to clients

Tiger Architecture ● Made from off-the-shelf products ● The cubs are identical computers with from 2 to 4 disk drives attached ● Cubs have two network cards, one Ethernet and one ATM ● The controller is another PC - responsible for the handling of client requests and the management of the work schedules of each of the cubs

Tiger Storage Organization ● Key design issue is the distribution of the video data among the disks attached to the cubs in order to enable them to share the load ● Movies are not stored on one single disk - they are striped across all disks (allowing different parts of the movie to be served by different cubs) ● Unfortunately, such an arrangement can result in system failure if a single cub fails ● A second mechanism, based on mirroring, provides a fault-tolerant storage facility to tolerate cub loss

Tiger Striping ● A movie is divided into (typically) one second blocks (referred to as "play-time") ● A two hour movie has 7200 blocks of playtime, which is 60 * 60 * 2 seconds (blocks) ● The set of movie blocks is stored evenly across all of the disks attached to the cubs using standard data striping techniques

Tiger Mirroring ● This scheme divides each block of play-time into several portions called "secondaries" ● The secondaries are stored (dispersed) among the other cubs ● When a cub fails, the extra workload of supplying the missing chunk of play-time is distributed and performed by several of the working cubs, and not just by one of them

Tiger Distributed Schedule ● The heart of Tiger's design is the scheduling of the workload for the cubs (performed by the controller) ● The schedule is organized as a list of "slots" - the work that must be done to play one block of any particular movie ● This work involves locating the next block, reading it from the appropriate disk from the relevant cub, then delivering it to the ATM network (which routes the block to the receiving PC) ● Tiger's scheduler performs well - with five cubs (each with three disks), the Tiger system can deliver up to 70 simultaneous video streams

Tiger Fault Tolerance ● As shown, striping results in a disruption to service for all clients whenever a single cub fails ● To fix this problem, Tiger retrieves data from the mirrored secondary copies whenever a primary block is unavailable ● Secondaries are themselves distributed so that they fall on several different disks attached to several different cubs ● This scheme works well, provided there is a small amount of spare capacity in the schedule

Tiger Network Support ● The block of play-time are simply passed to the ATM network by the cubs that hold them, together with the address of the receiving client ● The client needs sufficient buffer storage to hold two primary blocks (two chunks of play-time) - the one that is currently playing on screen and the next that is arriving from the network ● When working with primaries, the client need only check the sequence number of the next arriving block to ensure that all if OK ● When working with secondaries (parts of the play-time), the client has more work to do - receive all the secondaries, then reassemble them within its local buffer storage before playing