Upload
garry
View
33
Download
0
Embed Size (px)
DESCRIPTION
CS 414 – Multimedia Systems Design Lecture 35 – Media Server (Part 4). Klara Nahrstedt Spring 2012. Administrative. MP3 going on. Covered Aspects of Multimedia. Audio/Video Presentation Playback. Image/Video Capture. Audio/Video Perception/ Playback. Image/Video Information - PowerPoint PPT Presentation
Citation preview
CS 414 - Spring 2012
CS 414 – Multimedia Systems Design Lecture 35 – Media Server (Part 4)
Klara Nahrstedt
Spring 2012
Administrative
MP3 going on
CS 414 - Spring 2012
Covered Aspects of Multimedia
Image/VideoCapture
MediaServerStorage
Transmission
CompressionProcessing
Audio/VideoPresentationPlaybackAudio/Video
Perception/ Playback
Audio InformationRepresentation
Transmission
AudioCapture
A/V Playback
Image/Video InformationRepresentation
CS 414 - Spring 2012
Media Server Architecture
CS 414 - Spring 2012
Storage device
Disk controller
Storage management
File System
Memory Management (MaxBuf, MinBuf PolicyBuffering)
Content Distribution (Caching, Patching, Batching)
Network Attachment (RTP/RTCP, ….)
Incoming requestDelivered data
Outline Example of Early Media Server – Medusa
Example of Multimedia File System – Symphony
Example of Industrial Multimedia File System – Tiger Shark System
CS 414 - Spring 2012
CS 414 - Spring 2012
Source: Medusa (Parallel Video Servers), Hai Jin, 2004
Example of Media Server Architecture
Example Multimedia File System (Symphony)
CS 414 - Spring 2012
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
Design Decisions
CS 414 - Spring 2012
Two Level Symphony Architecture
CS 414 - Spring 2012
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
Disk Subsystem Architecture
CS 414 - Spring 2012
Service Manager : supports mechanisms for efficient scheduling of best-effort, aperiodic real-time and periodic real-time requestsStorage Manager: supports mechanisms for allocation and de-allocation of blocksOf different sizes and controlling data placement on the diskFault Tolerance layer: enables multiple data type specific failure recovery techniquesMetadata Manager: enables data types specific structure to be assigned to files
Cello Disk Scheduling Framework
CS 414 - Spring 2012Source: Prashant Shenoy, 2001
Class-Independent Scheduler
CS 414 - Spring 2012Source: Prashant Shenoy, 2001
Class-Specific Schedulers
CS 414 - Spring 2012
Validation: Symphony’s scheduling system (Cello)
CS 414 - Spring 2012
Source: Shenoy Prashant, 2001
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
Examples of caching policies for each cache buffer: LRU, MRU.CS 414 - Spring 2012
Buffer Subsystem (Protocol)
Receive buffer allocation request Check if the requested block is cached.
If yes, it retursn 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 414 - Spring 2012
Video Module
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 414 - Spring 2012
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 414 - Spring 2012
Symphony Caching Policy
Interval-based caching for video module LRU caching for text module
CS 414 - Spring 2012
IBM Multimedia File System
The Tiger Shark File System Roger L. Haskin, Frank B. Schmuck IBM Journal of Research and Development, 1998
CS 414 - Spring 2012
The newer MM Filesystems:Classes of requests Tiger Shark filesystem defines different types of classes to FS
requests. minimum needed is 2 classes.
Legacy Requests Read/Write data for small files, not needed quickly at the NIC
High-Performance Requests Read data for large likely-contiguous files that needs to be quickly dumped to
the nic (network interface control)
This is similar to our newer networking paradigm “not all traffic is equal”
Unaddressed question that I had: Can we take the concept of discardability and apply it to filesystems?
CS 414 - Spring 2012
Classes of Requests
Tiger Shark Real-time Class
Real-time class is fine grained into subclasses, because Tiger Shark has
Resource Reservation Admission Control
If the controllers and disks cannot handle the predicted load then the request is denied.
Legacy Class Also has a legacy interface for old filesystem access
interfaces.
CS 414 - Spring 2012
Quantization, and Scheduling Optimizations
"Deadline Scheduling" instead of elevator algorithms.
Blocksize is 256KB (default), Normal AIX uses 4KB size.
Tiger Shark will "chunk" contiguous block reads better than the default filesystems to work with its large blocksize.
CS 414 - Spring 2012
Streamlining of operations to get data from platter to NIC. Running daemon that pre-allocates OS resources
such as buffer space, disk bandwidth and controller time.
Not a hardware-dependent solution. Even though it does not have shared memory
hardware, Tiger Shark copies data from the disks into a shared memory area. Essentially this is a very large extension of the kernel's disk block cache.
CS 414 - Spring 2012
Seeking Optimizations
Byte Range Locking. Allows multiple clients to access different
areas of a file with real-time guarantees if they don't step on each other.
CS 414 - Spring 2012
Current Research and Future Directions Tiger Shark gives us Filesystem QoS. But can we do better by integrating VBR/ABR into the
system? Replication and redundancy are always an issue, but
not addressed in this scope. If it is a software-based system such as Tiger Shark,
where in the OS should we put these optimizations? (Kernel, Tack-On Daemon, Middleware)
Legacy disk accesses have a huge cost in both of these systems, how can we minimize?
CS 414 - Spring 2012
Tiger Shark Final Thoughts Adds QoS guarantees to current disk interface
architectures
Built to be extensible to more than just MM disk access. But definitely optimized for multimedia.
Designed to serve more concurrent sessions out of a multimedia server BUT there is still kernel bottleneck for the initial block
load. Better suited to multiple concurrent access than
EXT3NSCS 414 - Spring 2012
Conclusion
The data placement, scheduling, block size decisions, caching, concurrent clients support, buffering, are very important for any media server design and implementation.
Next Lecture – we discuss P2P Streaming
CS 414 - Spring 2012