Embed
Email

MM

Document Sample

Shared by: huanghengdong
Categories
Tags
Stats
views:
2
posted:
1/25/2012
language:
pages:
25
Outline



Introduction

Characteristics of multimedia data

Quality of service management

Resource management

Stream adaptation

Case study: Tiger video file server







1

*

Distributed Multimedia Systems









2

Distributed Multimedia Systems









 Applications:

– non-interactive: net radio and TV, video-on-demand, e-learning, ...

– interactive: voice &video conference, interactive TV, tele-medicine,

multi-user games, live music, ...



3

*

Characteristics of multimedia applications



 Large quantities of continuous data

 Timely and smooth delivery is critical

– deadlines

– throughput and response time guarantees

 Interactive MM applications require low round-trip delays

 Need to co-exist with other applications

– must not hog resources

 Reconfiguration is a common occurrence

– varying resource requirements

 Resources required:

– Processor cycles in workstations

– and servers

– Network bandwidth (+ latency) At the right time

– Dedicated memory and in the right quantities

– Disk bandwidth (for stored media)

4

*

Application requirements



 Network phone and audio conferencing

– relatively low bandwidth (~ 64 Kbits/sec), but delay times must be short ( <

250 ms round-trip)



 Video on demand services

– High bandwidth (~ 10 Mbits/s), critical deadlines, latency not critical



 Simple video conference

– Many high-bandwidth streams to each node (~1.5 Mbits/s each), high

bandwidth, low latency ( < 100 ms round-trip), synchronised states.



 Music rehearsal and performance facility

– high bandwidth (~1.4 Mbits/s), very low latency (< 100 ms round trip), highly

synchronised media (sound and video < 50 ms).







5

*

System support issues and requirements



 Scheduling and resource allocation in most current OS’s

divides the resources equally amongst all comers (processes)

– no limit on load

– \ can’t guarantee throughput or response time



 MM and other time-critical applications require resource

allocation and scheduling to meet deadlines

– Quality of Service (QoS) management

 Admission control: controls demand

 QoS negotiation: enables applications to negotiate admission and

reconfigurations

 Resource management: guarantees availability of resources for

admitted applications

– real-time processor and other resource scheduling





6

*

Characteristics of typical multimedia streams





Data rate Sample or frame

(approximate) size frequency



Telephone speech 64 kbps 8 bits 8000/sec

CD-quality sound 1.4 Mbps 16 bits 44,000/sec

Standard TV video 120 Mbps up to 640 x 480 24/sec

(uncompressed) pixels x 16 bits

Standard TV video 1.5 Mbps variable 24/sec

(MPEG-1 compressed)

HDTV video 1000–3000 Mbps up to 1920 x 1080 24–60/sec

(uncompressed) pixels x 24 bits

HDTV video 10–30 Mbps variable 24–60/sec

MPEG-2 compressed)

7

*

Typical infrastructure components for multimedia applications

Figures 15.4 & 15.5

PC/workstation PC/workstation Window

: multimedia stream system

Camera K

White boxes represent media A G H

processing components, many Codec Codec

of which are implemented

B L

in software, including: Microphones

Mixer

codec: coding/decoding filter Network

mixer: sound-mixing component Screen C connections Video file system Video

D M store

Codec

Window system



Component Bandwidth Latency Loss rate Resources required

Camera Out: 10 frames/sec, raw video Zero

640x480x16 bits



 Codec application involves multiple concurrent ms CPURAM 100 ms; the

A

This In:

Out:

10 frames/sec, raw video Interactive Low

MPEG-1 stream

10

processes in

10 Mbytes

each



PCs In:

B Mixer 2 44 kbps audio Interactive Very low 1 ms CPU each 100 ms;

Out: 1 44 kbps audio 1 Mbytes RAM

 Window applications may also Interactive Low concurrently 100 ms;

H Other In: various be running 5 ms CPU each on the

system Out: 50 frame/sec framebuffer 5 Mbytes RAM

same computers

K Network In/Out: MPEG-1 stream, approx. Interactive Low 1.5 Mbps, low-loss

connection 1.5 Mbps stream protocol

 Network all share processing and network low 44 kbps, very low-loss

L

They In/Out: Audio 44 kbps Interactive Very

resources

connection stream protocol

8

*

Quality of service management



 Allocate resources to application processes

– according to their needs in order to achieve the desired quality of multimedia

delivery



 Scheduling and resource allocation in most current OS’s

divides the resources equally amongst all processes

– no limit on load

– \ can’t guarantee throughput or response time



 Elements of Quality of Service (QoS) management

– Admission control: controls demand

– QoS negotiation: enables applications to negotiate admission and

reconfigurations

– Resource management: guarantees availability of resources for

admitted applications

– real-time processor and other resource scheduling

9

*

The QoS manager’s task





Ad mi ssi on co ntro l QoS ne goti ation

Application c omponents s pecify their QoS

requirements to QoS manager

Fl ow spec.

QoS manager ev aluatesnew requirements

agains t the av ailable res ources.

Suff icient?

Yes No





Reserv e the reques ted res ources Negotiate reduced res ource prov ision with application.

Agreement?

Re sou rce con tract Yes No

Allow application to proceed

Do not allow application to proceed





Application runs with resources as Application notif ies QoS manager of

per res ourc e contract inc reas ed res ource requirements







10

*

QoS Parameters



Bandwidth

The RFC 1363 Flow Spec

– rate of flow of multimedia data

Protocol version

Latency Maximum transmission unit

– time required forBandwidth: Token bucket rate

the end-to-end transmission of a single data element

burstiness

Jitter Token bucket size

Maximum transmission rate maximum rate

 variation in latency :– dL/dt

Minimum delay noticed acceptable latency

Delay:

acceptable jitter

Loss rate Maximum delay variation

Loss sensitivity percentage per T

– the proportion of data elements that can be dropped or delivered late

maximum consec-

Loss: Burst loss sensitivity

utive loss

Loss interval T

Quality of guarantee value







11

*

Figure 15.8 The RFC 1363 Flow Spec



Protocol version

Managing the flow of multimedia data transmission unit

Maximum

Token bucket rate

Bandwidth: burstiness

Token bucket size



 Flows are variable

Maximum transmission rate maximum rate

Minimum delay noticed acceptable latency

Delay:

– video compression methods such as MPEG (1-4)delay variation onacceptable jitter

Maximum

are based

Loss sensitivity percentage per T

similarities between consecutive frames

Loss: Burst loss sensitivity

maximum consec-

utive loss

– can produce large variations in data rate Loss interval T

Quality of guarantee value



 Burstiness

– Linear bounded arrival process (LBAP) model:

 maximum flow per interval t = Rt + B (R = average rate, B = max. burst)

– buffer requirements are determined by burstiness

– Latency and jitter are affected (buffers introduce additional delays)



 Traffic shaping

– method for scheduling the way a buffer is emptied



12

*

Traffic shaping algorithms – leaky bucket algorithm



(a) Leaky bucket





process 1









process 2







analogue of leaky bucket:

– process 1 places data into a buffer in bursts

– process 2 in scheduled to remove data regularly in smaller amounts

– size of buffer, B determines:

 maximum permissible burst without loss

 maximum delay

13

*

Traffic shaping algorithms – token bucket algorithm



(b) Token bucket





process 1

tokens: permits to place x bytes process 2

into output buffer process 3 Token generator









Implements LBAP

– process 1 delivers data in bursts

– process 2 generates tokens at a fixed rate

– process 3 receives tokens and exploits them to deliver output as quickly as it

gets data from process 1

Result: bursts in output can occur when some tokens have accumulated

14

*

Admission control



Admission control delivers a contract to the application

guaranteeing: For each network connection:

For each computer: bandwidth

 cpu time, available at specific intervals latency

 memory For disks, etc.:

bandwifth

latency



Before admission, it must assess resource requirements and

reserve them for the application

– Flow specs provide some information for admission control, but not all - assessment

procedures are needed

– there is an optimisation problem:

 clients don't use all of the resources that they requested

 flow specs may permit a range of qualities

– Admission controller must negotiate with applications to produce an acceptable result



15

*

Resource management



e.g. for each computer:

 Scheduling of resources cpu time, available at specific intervals

to meet the existing guarantees: memory

Fair scheduling allows all processes some portion of the resources based on

EDF scheduling

fairness:

Each task specifies a deadline T and CPU seconds S to the scheduler for each

 E.g. round-robin scheduling (equal turns), fair queuing (keep queue lengths equal)

scheduler schedules the task to delivery of

work item (e.g. video frame). EDFMM because there are deadlines for therun at least

 not appropriate for real-time

before T (and pre-empts it after S if it hasn't yielded).

S seconds data

It has been shown that EDF will find a schedule that meets the deadlines, if

Real-time scheduling traditionally used in special OS for system control

applications e.g. S is likely schedulers must ensure that tasks are

one exists. (But for- MM,avionics. RTto be a millisecond or so, and there is a

that the by a scheduled have

danger completedscheduler may time. to run so frequently that it hogs the cpu).

Real-time MM requires real-time scheduling with very frequent deadlines.

Rate-monotonic scheduling assigns priorities to tasks according to tasks

Suitable types of scheduling are:

according to their rate of data throughput (or workload). Uses less CPU for

Earliest deadline first (EDF)

scheduling decisions. Has been shown to work well where total workload is <

Rate-monotonic

69% of CPU.





16

*

Scaling and filtering







Source

Targets





High bandwidth

Medium bandwidth

Low bandwidth





 Scaling reduces flow rate at source

– temporal: skip frames or audio samples

– spatial: reduce frame size or audio sample quality



 Filtering reduces flow at intermediate points

– RSVP is a QoS negotiation protocol that negotiates the rate at each

intermediate node, working from targets to the source.

17

*

QoS and the Internet



 Very little QoS in the Internet at present

– New protocols to support QoS have been developed, but their implementation

raises some difficult issues about the management of resources in the

Internet.



 IPv6 header layout

RSVP

– Network resource reservation

Flow

Version (4 bits)Priority (4bits) of reservations label (24 b its)

– Doesn’t ensure enforcement

Payload leng th (16 bits) Next h eader (8bits) Hop limit (8bits)

 RTP

– Real time data transmission over IP ad dress

Source

(1 28 bits)

 need to avoid adding undesirable complexity to the Internet

 IPv6 has some hooks for it

Destination ad dress

(1 28 bits)

18

*

Case Study Tiger Video File server



 Microsoft NetShow Video file server

Tiger

 Design goals

– Video on demand for a large number of users

– Quality of service

– Scalable and distributed Clients

– Low cost hardware

– Fault tolerant

Network









19

*

Tiger architecture



 Storage organization

– Striping

– Mirroring



 Distributed schedule

 Tolerate failure of any single computer or disk

 Network support

 Other functions

– pause, stop, start









20

*

Tiger hardware configuration



Controller

low-bandwidth network





0 n+1 1 n+2 2 n+3 3 n+4 n 2n+1



Cub 0 Cub 1 Cub 2 Cub 3 Cub n

high-bandwidth



ATM switching network



Cubs and controllers Start/Stop

are standard PCs requests from clients

video distribution to clients



Each movie is stored in 0.5 MB blocks (~7000) across all disks in the order of the disk

numbers, wrapping around after n+1 blocks.

Block i is mirrored in smaller blocks on disks i+1 to i+d where d is the decluster factor

(typically 4 - 8)

21

*

Distributed Schedule



 Scheduling of workload of cubs

– Slots

 Work required to serve on block of a movie

 One slot for each viewer (client)









22

Tiger schedule





2 1 block service 0

block play time T time t





slot 0 slot 1 slot 2 slot 3 slot 4 slot 5 slot 6 slot 7

viewer  client viewer state:

viewer 4 free free viewer 0 viewer 3 viewer 2 free viewer 1

state state state state state





Stream capacity of a disk = T/t (typically ~ 5) Viewer state: Network address of client

Stream capacity of a cub with n disks = n x T/t FileID for current movie

Number of next block

Cub algorithm:

Viewer's next play slot

1. Read the next block into buffer storage at the Cub.

2. Packetize the block and deliver it to the Cub’s ATM network controller with the

in time t address of the client computer.

3. 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.

4. Clients buffer blocks and schedule their display on screen.



23

*

Tiger performance and scalability



1994 measurements:

– 5 x cubs: 133 MHz Pentium Win NT, 3 x 2Gb disks each, ATM

network.

– supported streaming movies to 68 clients simultaneously without lost

frames.

– with one cub down, frame loss rate 0.02%



1997 measurements:

– 14 x cubs: 4 disks each, ATM network

– supported streaming 2 Mbps movies to 602 clients simultaneously with

loss rate of < .01%

– with one cub failed, loss rate <.04%

The designers suggested that Tiger could be scaled to 1000

cubs supporting 30,000 clients.

24

Summary



 MM applications and systems require new system

mechanisms to handle large volumes of time-dependent data

in real time (media streams).

 The most important mechanism is QoS management, which

includes resource negotiation, admission control, resource

reservation and resource management.

 Negotiation and admission control ensure that resources are

not over-allocated, resource management ensures that

admitted tasks receive the resources they were allocated.

 Tiger file server: case study in scalable design of a stream-

oriented service with QoS.



25



Related docs
Other docs by huanghengdong
6th-syllabus-Threet-2011-2012
Views: 0  |  Downloads: 0
Gina Cillo rd
Views: 0  |  Downloads: 0
szoftverfejlesztok.xls
Views: 1  |  Downloads: 0
cv-notes-exemple
Views: 0  |  Downloads: 0
Damascus Steel_seth Willouhby
Views: 0  |  Downloads: 0
UP_HolderReportingManual
Views: 0  |  Downloads: 0
4
Views: 0  |  Downloads: 0
ScienceFairLesson2
Views: 0  |  Downloads: 0
By registering with docstoc.com you agree to our
privacy policy

You are almost ready to download!

You are almost ready to download!