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

• f 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

• missions - 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

• rder 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
• verall 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 Cub 0 Cub 1 Cub 2 Cub 3 Cub n ATM switching network video distribution to clients Start/Stop requests from clients low-bandwidth network high-bandwidth

n+1 1 n+2

2

n+3 n+4 n

2n+1

3

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
• n 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

• n 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

More on Tiger

• The design called for the provision of fast-forward and rewind

support

• This is accomplished by delivering some fraction of the blocks in
• rder to give the visual feedback typically provided by video

recorders

• Initial problem: the controller is a single point-of-failure and a

potential scheduling/processing bottleneck

• The 1997 update redesigned the schedule management as a

distributed algorithm - management of the movie database is now performed by the cubs in conjunction with the controller

• Tiger is a good example of the changed design approach that is
• ften required for distributed multimedia applications

Performance and Scalability in Tiger

• Initial prototype developed in 1994 - five 133MHz

Pentium PCs, each with 48 Meg RAM and three 2 Gig SCSI disk drives and an ATM network controller - all PCs ran Windows NT

• Serving movies to 68 clients resulted in perfect delivery

when there was not faults within the system

• When one cub failed, a data loss rate of 0.02% was

measured

• Start-up latency was measured in the range of 2 to 12

seconds

More Recent Measurements

• A later experiment used a 14 cub, 56-disk configuration
• Movies delivered to 602 clients with a loss rate of one

block of play-time in 180,000 with all cubs functioning

• With one cub failure, less than 1 in 40,000 blocks was

lost

• MRL claim that Tiger can scale to 1000 cubs, servicing

from 30,000-40,000 simultaneous viewers

Summary

• Distributed multimedia applications require new system mechanisms

geared toward handling large volumes of time-dependent data

• The most important mechanisms are those concerned with QoS

management

• QoS parameters include bandwidth, latency and loss rates; QoS

management concerns itself with negotiation and admission control

• Earliest-deadline-first and Rate-monotonic real-time scheduling

algorithms are often employed to ensure that each stream element is processed in time

• Traffic shaping technologies buffer real-time data to smooth out

timing irregularities

• Scaling and filtering are useful stream adaptation techniques