Optimizing Disk Performance for a MultimediaStorage Server∗Ian Alderman Mamadou DialloAbstractOne potential bottleneck point in a multimedia server is the disk sys-tem. The capacity and sustained transfer rates for inexpensive disks haveincreased significantly in recent years, making it plausible to build a mul-timedia storage server from commodity hardware. However, currentlyavailable file systems were not designed for use with multimedia accesspatterns, which involve periodic transfer of large quantities of data withreal time constraints. We compare the performance of several differentmethods of accessing the disk system on Solaris and FreeBSD. We con-clude that the performance overhead of accessing data through existingfile systems outweighs the convenience advantage, and that schedulingdisk accesses to minimize seek times and reduce the variation in responsetime is important in providing peak performance.1 IntroductionNetworking technology promises to change the way we receive information. Al-though the new media has not yet replaced the old, applications such as in-teractive TV, on-demand course content, web based news supplemented withmultimedia, and the rise of economically feasible music distribution systemssuch as those recently proposed by Napster and mp3.com, indicate that thechange is coming.The popular adage is that, “A picture is worth a thousand words.” Indigital storage, it’s worse: a picture takes more than a thousand words worth ofstorage space, and continuous media, such as digital audio and video, takes upeven more. For example, an eight minute audio track encoded using MPEG-1,Layer 3 at 192 Kbps takes 11.25 MB to store. A one hour MPEG-1 video (1.5Mbps) takes 675 MB, And an MPEG-4 video of a 100 minute movie (4.0 Mbps)takes 3 GB to store. It is not feasible to store this quantity of data in memoryfor cost reasons: it must be stored on disk [6].Multimedia file servers built from commodity hardware can store hundredsof gigabytes of data, and serve hundreds of customers simultaneously. The∗This research was performed as course work for CS-736: Advanced Operating Systems,taught by Remzi Arpaci-Dusseau, in Fall 2000, at the University of Wisconsin, Madison. Testhardware was provided by the SWORD project.1performance of these servers is not necessarily constrained by network capacity,since modern switches and network cards can handle gigabit speeds, and a singleserver could be attached to the network through several NICs.Although disk capacity has increased significantly in recent years, disk per-formance has not increased as rapidly. In some prototype testing, we determinedthat a multimedia file server’s disk interface can exhibit poor performance if de-signed incorrectly. We built a simple application that read data in the mannerthat a multimedia server would if each stream was served by a single process. Weran one instance of this simple application and measured the performance. Thenwe ran several instances concurrently and noticed that the overall throughputfrom the disk decreased when several streams were being accessed simultane-ously.Our goal in this paper is to determine the fastest interface to the disk sys-tem for a multimedia file server running on commodity hardware. We com-pare several different methods of I/O, including read and pread, mmap, andasynchronous reads through implementations of the POSIX.2 standard. We at-tempted to allow the system to optimize the concurrency and ordering of diskrequests through system and user level threads, and compare the performance tosingle threaded versions. We compare the performance of FreeBSD and Solaris.2 MotivationStreaming media servers have different performance criteria from traditional fileservers. Continuous media has, on one hand, a real time constraint: clients mustreceive data on a stream before playback, and the time at which a segment ofa file must be received is determined by the time at which the client beginsplayback and the rate at which playback occurs. Although some jitter from thedisk system and from the network is acceptable, to provide smooth playback,it must be kept to a minimum. On the other hand, there is not a performancereason why a segment should be received much before it is needed, in fact, timelydelivery prevents exhausting client buffers. A key insight is that minimizing thetail of the response time distribution is more important for performance giventhe real time requirements of continuous media than minimizing the averageresponse time [11].Stated differently, blocks retrieved from a video file server are retrieved on astrict schedule, and missing deadlines in this schedule is acceptable only rarely.Our goals in performing this research included:• Quantifying the performance characteristics of various methods for access-ing continuous media data stored on disk.• Determining the maximum number of concurrent streams of data our testsystem could support given a certain playback rate, and the best methodfor retrieval.• Determining why some retrieval methods performed better than others.2• Contributing to the development of a video file server for the SWORDproject1, by providing a tool for the analysis of various design decisionssuch as the amount of memory included and the number of disks attached,and by providing a basis for the implementation of the disk interface forthis server.3 Related and future workDisk scheduling is a well understood area, and several groups have explicitlyaddressed the specific needs of multimedia storage systems [6, 10, 3, 5], as wellas comparing various approaches to striping multimedia data across several disksfor load balancing [7, 11, 9]. However, none of these papers explicitly measuredisk performance, nor do they compare the performance of interfaces such asraw I/O and FFS.We hope to expand the research summarized in this paper to test new tech-niques to improve the performance of our storage server prototype. One obviousaddition would be to include several disks in the benchmarks to determine theimplementation complexity and assess the potential for contention on the systemand SCSI busses.In the database community, it is recognized that managing disks directlyallows the application developer to perform optimizations explicitly, and pre-vents the operating system from attempting unsuitable optimizations [8]. Wehave quantified these differences specifically for the multimedia storage serverapplication, which has quite different