NJIT 1 Distributed Multimedia Systems Coulouris, Dollimore and Kindberg, Distributed Systems,...
-
Upload
hollie-lester -
Category
Documents
-
view
219 -
download
1
Transcript of NJIT 1 Distributed Multimedia Systems Coulouris, Dollimore and Kindberg, Distributed Systems,...
NJIT1
Distributed Multimedia Systems
Coulouris, Dollimore and Kindberg, Distributed Systems, Concepts and
Design, Chapter 17
Prepared by:
Pravin Kumar Katragadda
2
Introduction
Modern computers can handle streams of continuous, time-based data such as digital audio applications and video.
This capability has led to the development of distributed multimedia applications.
3
Introduction (contd..)
The requirements of multimedia applications significantly differ from real-time applications: Multimedia applications are highly distributed
and therefore compute with other distributed applications for network bandwidth and computing resources.
The resource requirements of multimedia applications are dynamic.
4
Figure 17.1 A distributed multimedia system
Wide area gateway Videoserver
DigitalTV/radioserver
Video cameraand mike
Local network Local network
5
Distributed Multimedia System
The above figure illustrates a typical distributed multimedia system, capable of supporting a variety of applications such as desktop conferencing, video-on-demand services, accessing stored video sequences using web-based multimedia and broadcast digital TV/ radio.
6
Web-based multimedia
These applications provide best effort access to streams of audio and video data published via the Web.
Their performance is constrained with limited bandwidth and variable latencies found in current networks.
These applications are most successful when there is little need for the synchronization of data streams.
7
Network phone and audio conferencing
These applications have relatively low bandwidth requirements when efficient compression techniques are used.
However, its interactive nature demands low round-trip delays which are not always achievable.
8
Video-on-demand services
These supply video information in digital form, retrieving data from large online storage systems and delivering them to user’s display.
These are successful only when dedicated network bandwidth is available and where the video server and the receiving stations are dedicated.
9
Figure 17.2 Window of scarcity for computing and communication
1980 1990
remotelogin
networkfile access
high-qualityaudio
interactivevideo
insufficientresources
scarceresources
abundantresources
2000
10
The Window of Scarcity
Many of today’s computer systems provide some capacity to handle multimedia data, but the necessary resources are very limited.
Especially, when dealing with large audio and video streams many systems are constrained in the quantity and quality of streams they can support. This situation is depicted as the Window of Scarcity.
11
The Window of Scarcity operation
If a certain class of application lies within this window, a system needs to allocate and schedule its resources carefully in order to provide the desired service.
Before the window of scarcity is reached, a system has insufficient resources to execute relevant applications.
Once an application class has left the window of scarcity, system performance will be sufficient to provide the service even under adverse circumstances.
12
Figure 17.3 Characteristics of typical multimedia streams
Data rate(approximate)
Sample or frame size frequency
Telephone speech 64 kbps 8 bits 8000/secCD-quality sound 1.4 Mbps 16 bits 44,000/secStandard TV video(uncompressed)
120 Mbps up to 640 x 480pixels x 16 bits
24/sec
Standard TV video (MPEG-1 compressed)
1.5 Mbps variable 24/sec
HDTV video(uncompressed)
1000–3000 Mbpsup to 1920 x 1080pixels x 24 bits
24–60/sec
HDTV videoMPEG-2 compressed)
10–30 Mbps variable 24–60/sec
13
Characteristics of multimedia data
Multimedia data (video and audio) is continuous and time-based. Continuous data is represented as sequence of
discrete values that replace each other over time. Time-based (or isochronous data) is so called because
timed data elements in audio and video streams define the semantics or content of the stream. The time at which the values are played effect the validity of the data. Hence, the timing should be preserved.
Multimedia systems are often bulky. Hence the data should be moved with greater throughput.
14
Characteristics of multimedia data (contd..)
Figure 17.3 shows typical data rates and frame/sample frequencies.
The resource bandwidth requirements for some are very large especially for video of reasonable quality.
A standard TV/Video stream requires more than 120 Mbps.
The figures for HDTV are even higher and in video-conferencing there is a need to handle multiple streams concurrently. Hence compression is used.
15
QoS Management
When multimedia run in networks of PCs, they compete for resources at workstations running the applications and in the network.
In multi-tasking operating system, the central processor is allocated to individual tasks in a Round-Robin or other scheduling scheme.
The key feature of these schemes is that they handle increases in demand by spreading the available resources more thinly between the competing tasks.
16
QoS Management (contd..)
The timely processing and transmission of multimedia streams in crucial. In order to achieve timely delivery, applications need guarantees that the necessary resources will be allocated and scheduled at the required times.
The management and allocation of resources to provide such guarantee is referred to as Quality of Service Management (QoS Management)
17
Figure 17.4 Typical infrastructure components for multimedia applications
Microphones
Camera
Screen
Window system
CodecD
BMixer
PC/workstation PC/workstation
CVideostore
Networkconnections
K
L
M
: multimedia stream
CodecA G
Codec
H
Window system
White boxes represent media processing components, many of which are implemented in software, including:codec: coding/decoding filter
mixer: sound-mixing component
Video file system
18
Typical infrastructure components for multimedia applications (contd..)
The above figure shows the most commonly used abstract architecture for multimedia software.
Continuously flowing streams of media data elements are processed by a collection of processed and transferred between the processes by inter-process connections.
The processes produce, transform and consume continuous streams of multimedia data.
19
Typical infrastructure components for multimedia applications (contd..)
The connections link the processes in a sequence from a source of media elements to a target.
For the elements of multimedia data to arrive at their target on time , each process must be allocated adequate resources to perform its task and must be scheduled to use the resources sufficiently frequently to enable it to deliver the data elements in its stream to the next process on time.
20
Figure 17.5 QoS specifications for components in Figure 17.4
Component Bandwidth Latency Loss rate Resources required
Camera Out: 10 frames/sec, raw video640x480x16 bits
Zero
A Codec In:Out:
10 frames/sec, raw videoMPEG-1 stream
Interactive Low 10 ms CPU each 100 ms;10 Mbytes RAM
B Mixer In:Out:
2 44 kbps audio1 44 kbps audio
Interactive Very low 1 ms CPU each 100 ms;1 Mbytes RAM
H Windowsystem
In:Out:
various50 frame/sec framebuffer
Interactive Low 5 ms CPU each 100 ms; 5 Mbytes RAM
K Networkconnection
In/Out: MPEG-1 stream, approx.1.5 Mbps
Interactive Low 1.5 Mbps, low-lossstream protocol
L Networkconnection
In/Out: Audio 44 kbps Interactive Very low 44 kbps, very low-lossstream protocol
21
QoS specifications for components
The figure 17.5 sets out the resource requirements for the main software components and network connections (in Fig 17.4)
The required resources can be guaranteed only if there is a system component responsible for the allocation and scheduling of those resources.
We refer to that as the Quality of Service (QoS) manager.
22
Figure 17.6The QoS manager’s task
Application components specify their QoS requirements to QoS manager
Yes No
Yes No
Flow spec.
Resource contract
Admission control QoS negotiation
QoS manager evaluates new requirementsagainst the available resources.
Sufficient?
Reserve the requested resources
Allow application to proceed
Application runs with resources as per resource contract
Negotiate reduced resource provision with application.Agreement?
Do not allow application to proceed
Application notifies QoS manager of increased resource requirements
23
QoS Manager’s Tasks
The QoS Manager’s two main subtasks are: Quality of Service Negotiation Admission control
24
QoS Negotiation
The application indicates its resource requirements to the QoS manager.
To Negotiate QoS between an application and its underlying system an application must specify its QoS requirements to the QoS manager.
This is done by transmitting a set of parameters.
25
QoS Negotiation Parameters
Bandwidth: The rate at which data flows through a multimedia stream.
Latency: It is the time required for an individual data element to move through a stream from the source to the destination.
Loss Rate: The rate at which the data elements are dropped due to untimely delivery.
26
Traffic Shaping
Traffic shaping is the term used to describe the use of output buffering to smooth the flow of data elements.
The bandwidth parameter of a multimedia stream provides an idealistic approximation of the actual traffic pattern.
The closer the actual pattern matches the description, the better the system will handle the traffic.
27
LBAP Model of bandwidth variations
This calls for the regulation of burstiness of the multimedia streams.
Any stream can be regulated by inserting a buffer at the source and by defining a method by which data elements leave the buffer.
This can be illustrated using following algorithms: Leaky Bucket Token Bucket
28
Figure 17.7Traffic shaping algorithms
Token generator
(a) Leaky bucket (b) Token bucket
29
Leaky Bucket Algorithm
The bucket can be filled arbitrarily with water until it is full. Through a leak at the bottom of the bucket water will flow out.
The algorithm ensures that a stream will never flow at a rate higher than R.
The size of the buffer B defines the maximum burst a string an incur without losing elements.
This algorithm completely eliminates bursts.
30
Token Bucket Algorithm
The elimination of bursts in the previous algorithm is not necessary as long as bandwidth is bounded over any time interval.
The token bucket algorithm allows larger bursts to occur when the stream has been idle for a while.
Tokens are generated at a rate R and collected in a bucket of size B. Data can be sent only when atleast S tokens are in bucket.
This ensures that over any interval t the amount of data sent is not larger than Rt+B
31
Figure 17.8The RFC 1363 Flow Spec
Protocol version
Maximum transmission unit
Token bucket rate
Token bucket size
Maximum transmission rate
Minimum delay noticed
Maximum delay variation
Loss sensitivity
Burst loss sensitivity
Loss interval
Quality of guarantee
Bandwidth:
Delay:
Loss:
32
Flow Specifications
A collection of QoS parameters is typically known as a flow specification, or flow spec for short.
Several examples for flow spec exists. In Internet RFC 1363 , a flow spec is defined as a 16-bit numeric values, which reflect the QoS parameters.
33
QoS Admission Control
Admission control regulates access to resources to avoid resource overload and to protect resources from requests that they cannot fulfill.
An admission control scheme is based on the overall system capacity and the load generated by each application.
34
QoS Admission Control
Bandwidth reservation: A common way to ensure a certain QoS level for a multimedia stream is to reserve some portion of resource bandwidth for its exclusive use.
Statistical multiplexing: It is based on the hypothesis that for a large number of streams the aggregate bandwidth required remains nearly constant regardless of the bandwidth of individual streams.
35
Resource Management
To provide a certain QoS level to an application, a system needs to have sufficient resources, it also needs to make the resources available to an application when they are needed (scheduling).
Resource Scheduling: A process needs to have resources assigned to them according to their priority. Following 2 methods are used: Fair Scheduling Real-time scheduling
36
Fair Scheduling
If several streams compete for the same resource, it becomes necessary to consider fairness and to prevent ill-behaved streams taking too much bandwidth.
A straight forward approach is to apply round-robin scheduling to all streams in the same class, to ensure fairness.
In Nagle, a method was introduced on a packet-by-packet basis that provides more fairness w.r.t varying packet sizes and arrival times. This is called Fair Queuing.
37
Real-time scheduling
Several algorithms were developed to meet CPU scheduling needs of applications.
Traditional real-time scheduling methods suit the model of regular continuous multimedia streams very well. Earliest-Deadline-First (EDF) scheduler uses
a deadline i.e. associated with each of its work items to determine the next item: The item with earliest deadline goes in first.
38
Stream Adaptation
The simplest form of adjustment when QoS cannot be guaranteed is adjusting its performance by dropping pieces of information.
Two methodologies are used: Scaling Filtering
39
Scaling Best applied when live streams are sampled. Scaling algorithms are media-dependent, although
overall scaling approach is the same: to subsample a given signal.
A system to perform scaling consists of a monitor process at the target and a scalar process at the source.
Monitor keeps track of the arrival times of messages in a stream. Delayed messages are an indication of bottle neck in the system.
Monitor sends a scale-down message to the source that scales up again .
40
Figure 17.9 Filtering
SourceTargets
High bandwidth
Medium bandwidth
Low bandwidth
41
Filtering
It is a method that provides the best possible QoS to each target by applying scaling at each target by applying scaling at each relevant node on the path from source to the target.
Filtering requires that a stream be partitioned into a set of hierarchical substreams, each adding a higher level of quality.
A substream is not filtered at an intermediate node if somewhere downstream a path exists that can carry the entire substream.
42
Case study: The Tiger video file server
A video storage system that supplies multiple real-time video streams simultaneously is an important component to support consumer oriented multimedia applications.
One of the most advanced prototypes of these is the Tiger video file server.
43
Design Goals
Video-on-demand for a large number of users.
Quality of Service Scalable and distributed Low cost hardware Fault tolerant
44
Figure 17.10 Tiger video file server hardware configuration
Controller
Cub 0 Cub 1 Cub 2 Cub 3 Cub n
ATM switching network
video distribution to clientsStart/Stop
requests from clients
low-bandwidth network
high-bandwidth
0 n+1 1 n+2 2 n+3 n+4 n 2n+13
45
Architecture
The cub computers shown in the Fig 17.10 are identical PCs with the same number of hard disk drives attached to each.
They are equipped with Ethernet and ATM network cards.
The controller is another PC, not involved in the handling of multimedia data and only responsible for handling client requests and the management of work schedules for the cubs.
46
Storage Organization
The key design issue is the distribution of video data among the disks attached to the cubs in order to enable them to share the load.
Schemes used: Striping, Mirroring Movies are stored in striped representation
among all disks. This could lead to a gap in the sequence of every movie if a disk fails. This is overcome by a storage mirroring scheme that replicates the data and a fault tolerance mechanism.
47
Distributed schedule
The heart of the Tiger’s design is the scheduling of the workload for the cubs. The schedule is organized as a list of slots where each slot represents the work that must be done.
There is exactly one slot for each potential client and each occupied slot represents 1 viewer receiving a real-time video data stream.
48
Distributed schedule (contd..)
The viewer state is represented by : Address of the client computer Identity of the file being played Viewer’s position in the file The viewer’s play sequence number Bookeeping information
49
Figure 17.11 Tiger schedule
012
slot 0
viewer 4
slot 1
free
slot 2
free
slot 3
viewer 0
slot 4
viewer 3
slot 5
viewer 2
slot 6
free
slot 7
viewer 1
block play time Tblock service
time t
state state state state state
50
Tiger Schedule
The block play time T is the time that is required by a viewer to display a block on the client computer.
Tiger must therefore maintain a time interval T between delivery times of the blocks.
Each cub maintains a pointer into the schedule for each disk that it controls.
51
Tiger Schedule (contd..)
The cub steps through the schedule in real-time processing slots as follows: Read the next block into buffer storage at the
cub. Packetize the block and deliver it to the cub’s
ATM network controller with the address of the client computer.
Update viewer state in the schedule to show the new next block and play sequence number and pass the updated slot to the next cub.
52
George Coulouris, Jean Dollimore and Tim Kindberg, Distributed Systems, Concepts and Design, Addison Wesley, Fourth Edition, 2005
Figures from the Coulouris text are from the instructor’s guide and are copyrighted by Pearson Education 2005
Bibliography