1. CS 414 – Multimedia Systems Design Lecture 31 – Media Server (Part 5)
Klara Nahrstedt
Spring 2010
CS Spring 2010

2. Administrative MP3 due today, April 12 Demonstrations 5-7pm in 216 SC
Sign up in Monday class (today) for the demo slot
CS Spring 2010

3. Outline VOD Optimization Techniques
Caching, Patching, Batching
Example of Multimedia File System - Symphony
Two-level Architecture
Cello Scheduling Framework at Disk Management level
Buffer Subsystem
Video Module
Caching
CS Spring 2010

4. Caching in Media Servers
Interval-based
Frequency-based
Source: “preemptive, but safe interval caching for real-time multimedia
systems “Lee et al. 2003
CS Spring 2010

5. Patching Stream tapping or patching – technique to support true VOD;
Patching assumes multicast transmission and clients arriving late to miss the start of main transmission
These late clients immediately receive main transmission and store it temporarily in a buffer.
In parallel, each client connects to server via unicast and transports (patches) the missing video start which can be shown immediately
CS Spring 2010

6. Types of Patching Greedy Patching Grace Patching
a new main transmission is started only if the old one has reached the end of the video
Clients arriving in between create only patching transmissions
Grace Patching
If a new client arrives and the ongoing main transmission is at least T seconds old, then the server automatically starts a new main transmission which plays whole video from the start again.
CS Spring 2010

7. Batching
Batching – grouping clients requesting the same video object that arrives within a short duration of time or through adaptive piggy-backing
Increasing batching window increases the number of clients being served simultaneously, but also increases reneging probability
reneging time – amount of time after which client leaves VOD service without delivery of video
Increasing minimum wait time increases client reneging
Performance metrics: latency, reneging probability and fairness
Policies:
FCFS, MQL (Maximum Queue Length), FCFS-n
CS Spring 2010

8. Batching Policies
FCFS: schedules the batch whose first client comes earliest, with the aim of achieving some level of fairness
Maximum Queue Length: schedules the batch with largest batch size, with the aim of maximizing throughput
FCFS-n: schedules the playback of n most popular videos at predefined regular intervals and service the remaining in FCFS order
CS Spring 2010

9. Source: “Selecting among Replicated Batching VOD Servers, Guo et al
CS Spring 2010

10. Examples of Real Video Server Systems
Medusa
Symphony
Alcatel-Lucent 5910 Streaming Server
CS Spring 2010

11. Example of Media Server Architecture
Source: Medusa (Parallel Video Servers), Hai Jin, 2004
CS Spring 2010

12. Factors affecting Optimal Block Size
Server Configuration
Number of disks in the array
Physical characteristics of disks
Type of disk array (i.e., redundant vs. non-redundant
Client Characteristics
Number of clients accessing the server
Client request size
Objective: given server configuration, client characterization, determine the optimal block size
CS Spring 2010

13. Selecting Metrics Aperiodic accesses -=> client-pull architecture
Text
Aperiodic accesses -=> client-pull architecture
Best effort => minimize response time
Graph Source: Shenoy Prashant, U. Mass., 2001
CS Spring 2010

14. Selecting Metric Continuous Media Metric: Minimize service time
Periodic and sequential access => server-push architecture
Real-time => minimize tail of response time distribution
Metric: Minimize service time
of the most heavily loaded disk
Graph Source: Shenoy Prashant,
U. Mass., 2001
CS Spring 2010

15. Example Multimedia File System (Symphony)
Source: P. Shenoy et al, “Symphony: An Integrated Multimedia File System”, SPIE/ACM MMCN 1998
System out of UT Austin
Symphony’s Goals:
Support real-time and non-real time request
Support multiple block sizes and control over their placement
Support variety of fault-tolerance techniques
Provide two level metadata structure that all type-specific information can be supported
CS Spring 2010

16. Design Decisions
CS Spring 2010

17. Two Level Symphony Architecture
Resource Manager:
Disk Schedule System (called Cello) that uses modified SCAN-EDF for RT
Requests and C-SCAN for non-RT requests as long as deadlines are not violated
Admission Control and Resource Reservation for scheduling
CS Spring 2010

18. Disk Subsystem Architecture
Service Manager : supports mechanisms for efficient scheduling of best-effort,
aperiodic real-time and periodic real-time requests
Storage Manager: supports mechanisms for allocation and de-allocation of blocks
Of different sizes and controlling data placement on the disk
Fault Tolerance layer: enables multiple data type specific failure recovery techniques
Metadata Manager: enables data types specific structure to be assigned to files
CS Spring 2010

19. Cello Disk Scheduling Framework
Source: Prashant Shenoy, 2001
CS Spring 2010

20. Class-Independent Scheduler
CS Spring 2010
Source: Prashant Shenoy, 2001

21. Class-Specific Schedulers
CS Spring 2010

22. Validation: Symphony’s scheduling system (Cello)
Source: Shenoy Prashant, 2001
CS Spring 2010

23. Buffer Subsystem
Enable multiple data types specific caching policies to coexist
Partition cache among various data types and allow each caching policy to independently manage its partition
Maintain two buffer pools:
a pool of de-allocated buffers
pool of cached buffers.
Cache pool is further partitioned among various caching policies
Buffer that is least likely to be accessed is stored at the head of the list. (Examples of caching policies for each cache buffer: LRU, MRU)
CS Spring 2010

24. Buffer Subsystem (Protocol)
Receive buffer allocation request
Check if the requested block is cached.
If yes, it return the requested block
If cache miss, allocate buffer from the pool of de-allocated buffers and insert this buffer into the appropriate cache partition
Determine (Caching policy that manages individual cache) position in the buffer cache
If pool of de-allocated buffers falls below low watermark, buffers are evicted from cache and returned to de-allocated pool
Use TTR (Time To Reaccess) values to determine victims
TTR – estimate of next time at which the buffer is likely to be accessed
CS Spring 2010

25. Video Module Retrieval Policy:
Implements policies for placement, retrieval, metadata management and caching of video data
Placement of video files on disk arrays is governed by two parameters: block size and striping policy.
supports both fixed size blocks (fixed number of bytes) and variable size blocks (fixed number of frames)
uses location hints so as to minimize seek and rotational latency overheads
Retrieval Policy:
supports periodic RT requests (server push mode) and aperiodic RT requests (client pull mode)
CS Spring 2010

26. Video Module (Metadata Management)
To allow efficient random access at byte level and frame level, video module maintains two-level index structure
First level of index , referred to as frame map, maps frame offset to byte offset
Second level, referred to as byte map, maps byte offset to disk block locations
CS Spring 2010

27. Caching Policy Interval-based caching for video module
LRU caching for text module
CS Spring 2010

28. Conclusion
The data placement, scheduling, block size decisions, caching are very important for any media server design and implementation.
CS Spring 2010