Unformatted text preview:

CS 414 – Multimedia Systems Design Lecture 30 – Media Server (Part 6) AdministrativeOutlineExample Multimedia File System (Symphony)Design DecisionsTwo Level Symphony ArchitectureDisk Subsystem ArchitectureCello Disk Scheduling FrameworkClass-Independent SchedulerClass-Specific SchedulersValidation: Symphony’s scheduling system (Cello)Buffer Subsystem Buffer Subsystem (Protocol) Video ModuleVideo Module (Metadata Management) Symphony Caching Policy IBM Multimedia File System The newer MM Filesystems: Classes of requestsClasses of RequestsQuantization, and Scheduling OptimizationsStreamlining of operations to get data from platter to NIC.Platter Layout and Scaling Optimizations for Contiguous StreamingSeeking OptimizationsCurrent Research and Future DirectionsTiger Shark Final ThoughtsConclusionCS 414 - Spring 2011CS 414 – Multimedia Systems DesignLecture 30 –Media Server (Part 6) Klara NahrstedtSpring 2011Administrative MP3 going onCS 414 - Spring 2011Outline Example of Multimedia File System - Symphony Two-level Architecture Cello Scheduling Framework at Disk Management level Buffer Subsystem Video Module Caching Example of Industrial Multimedia File System – Tiger Shark System CS 414 - Spring 2011Example Multimedia File System (Symphony)CS 414 - Spring 2011 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 supportedDesign DecisionsCS 414 - Spring 2011Two Level Symphony ArchitectureCS 414 - Spring 2011Resource 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 schedulingDisk Subsystem ArchitectureCS 414 - Spring 2011Service 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 filesCello Disk Scheduling FrameworkCS 414 - Spring 2011Source: Prashant Shenoy, 2001Class-Independent SchedulerCS 414 - Spring 2011Source: Prashant Shenoy, 2001Class-Specific SchedulersCS 414 - Spring 2011Validation: Symphony’s scheduling system (Cello)CS 414 - Spring 2011Source: Shenoy Prashant, 2001Buffer 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 414 - Spring 2011Buffer 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 accessedCS 414 - Spring 2011Video 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 2011Video 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 locationsCS 414 - Spring 2011Symphony Caching Policy  Interval-based caching for video module  LRU caching for text moduleCS 414 - Spring 2011IBM Multimedia File System  The Tiger Shark File System Roger L. Haskin, Frank B. Schmuck IBM Journal of Research and Development, 1998The 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?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.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.Streamlining of operations to get data from platter to NIC. Running daemon that pre-allocates OS resources such as buffer space, disk


View Full Document

U of I CS 414 - Media Server (Part 6)

Documents in this Course
Lecture 1

Lecture 1

32 pages

LECTURE

LECTURE

30 pages

Load more
Download Media Server (Part 6)
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Media Server (Part 6) and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Media Server (Part 6) 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?