0018-9162/01/$10.00 © 2001 IEEE64 Computer

R E S E A R C H F E A T U R E

An Efficient Video-on-Demand Model

An efficient video-on-demand system lets cus-tomers select movies from a large menu toview in their homes at times of their choos-ing. A VoD system includes three compo-nents—the server, a communications net-

work, and terminals connected to television sets. At any time, the system can serve thousands of cus-

tomers. Each customer’s VoD terminal connects to aTV and the network. Using the network, the customercontacts the VoD provider to request a movie at a spe-cific time.

The server’s many disks contain digitized, com-pressed movie files. The server sends bursts of datafrom the movie file to the user’s terminal, which tem-porarily stores the data in a buffer. The terminal con-currently decompresses the data received from thebuffer and sends it in real time to the TV for onscreendisplay.

The movie should play smoothly without interrup-tion, unless the user decides to pause. The VoD net-work’s bandwidth must permit data transfer at a rateequal to or exceeding the rate at which the TV con-sumes the data. The terminal buffer capacity shouldbe sufficiently large to permit uninterrupted movieplaying despite variable data receipt by the terminalor variations in the data decompression rate. The fol-lowing parameters provide some perspective to thisscenario:

• A common consumption rate for the compresseddata in the terminal is approximately 0.5 Mbyteper second, using the MPEG-2 video compressionstandard.1

• A two-hour movie occupies 3.6-Gbyte storage atthis rate.

• A 1-Mbyte terminal buffer stores enough com-pressed data to provide, on average, 2 seconds ofmovie time.

• A modern disk suitable for this application typi-cally provides data at 20 Mbytes per second.

• A 15-Gbyte disk can store four two-hour movies.

The following queries raise important design issuesfor an efficient VoD system:

• How should the disks store the movie files?• How should the server schedule the reading of

blocks from the files?• How large should the terminal buffer be?• How much buffer space should the server have?• How should the server manage buffer space?• When should the server deny a new movie request?• When should the server start a new movie?• How can the server support features such as

pause and fast forward?• How can the server efficiently provide access to

infrequently requested movies?• How and to what extent can the system benefit

from piggybacking so that a single movie streamcan accommodate two requests for the samemovie at about the same time?

Researchers have proposed and analyzed severaldisk-scheduling algorithms, including the elevatoralgorithm,2-4 earliest deadline first (EDF),4,5 a com-bined elevator and round-robin scheme called “groupsweeping,”3 a real-time priority scheduler includingprefetching algorithms,2 a combined elevator and EDFalgorithm,5 and algorithms for applications involvinga mixture of continuous media and discrete requests.6

Developers have described data layout on disks(including data striping and interleaving),2,4 bufferingschemes,2,4,5 and techniques for pause, fast forward,and so forth.

Earlier work focused on objectives that were notessential to the development of realistic VoD systems.

An efficient video-on-demand system uses a practical, technologicallysophisticated model to serve the viewing needs of a wide audience, including meeting the peak demand for popular, newly released films.

William E.WrightSouthern IllinoisUniversity atCarbondale

May 2001 65

For example, many designs considered deadlines, pri-orities, and prefetching to avoid glitches in the nearterm. The developers analyzed algorithms based onthe maximum number of simultaneous user videostreams they could support without a glitch,2,5 theminimum amount of buffer space required,3 or the response time for discrete requests.6 They basedmany of these studies on worst-case scenarios or sim-ulation results.

OEID—one-way elevator with interleaving anddelayed start—maximizes the VoD system’s overalllong-term efficiency and serves the maximum numberof users regardless of movie popularity. The designincludes the appropriate scheduling algorithm, bufferpolicy, file-storage layout, and a mechanism for deal-ing with the system’s saturation. OEID provides anoptimal model for a practical, realistic VoD system thateffectively addresses a number of key design issues.

DISK PARAMETERSTable 1 lists OEID’s notation. Using specific hardware parameters for modern disk

devices shows practical relevance and facilitates con-ceptualization. The disk specifications listed in Table2 are similar to those used for a Quantum Atlas V diskdrive,7 a device that is suitable for a server. Even ifthese parameters change, the optimal design is stillappropriate for a wide range of values. Some num-bers in Table 2 are rounded to simplify the arithmetic.

My proposed design effectively exploits the extraintelligence that modern disk systems commonly pro-vide, such as caching, zero-latency read, track andcylinder skewing, and command reordering.8

ALGORITHMSThe most important algorithm determines the

sequence of disk reads to support the video streams’needs. The server brings data blocks into random-access memory in an appropriate sequence to trans-mit it to the proper terminals so that no terminalstarves. OEID thus strives to maximize the number ofvideo streams that terminals can serve concurrently.

All streams exhaust data at the same rate, exceptfor the random fluctuations that varying compressionrates cause. Serving the terminals in rounds, readingat most one data block for each stream in each round,is the best way to maximize system performance. Ifsufficient data from the previous read remains in thestream buffer, the round does not read the block.

A one-way elevator provides the best schedulingalgorithm. As Figure 1 shows, the OE algorithm func-tions like an elevator that goes from the bottom to thetop floor, making stops as needed at floors along theway, but then drops as fast as possible to the bottomfloor without stopping or slowing down. During around, the reading of each disk proceeds approxi-

mately from the outermost cylinder and lowest tracknumber needing to be read to the innermost cylinderand highest track number needing to be read.Following this process, a full-stroke seek back to theoutermost cylinder needing to be read positions theaccess arm for the next round. The algorithm can alsobe given with the in-out directions reversed.

I use the term “approximately” to describe eachdisk read during a round because the scheduling algo-rithm permits the disk controller to exploit its capa-bilities for command reordering, a procedure thatgreatly improves system performance.8 For example,to take advantage of a reduced latency, the disk con-troller can seek past one needed cylinder to readanother, then seek backward to pick up the earliercylinder. The scheduling algorithm gives the sequenceof read requests for the round to the controller, thereby

Table 1. OEID notation.

Notation Specification

s Average seek time for a disk access, including settle time

R Time for one rotationr Average latency (rotational delay)tt Average transfer timea Average total access time, a = s + r + tttr Transfer ratecr Consumption rate—rate at which

the system uses compressed data to generatethe movie in real time

m Number of disks available at the serverk Number of striped disks in a groupg Number of groups (m = k × g)ng Maximum number of video streams

a group supports n Maximum number of video streams the

system supports (n = g × ng)b Data block size—amount of data to read

for a video stream during a roundss Stripe size (ss = b/k)

Table 2. OEID disk specifications.

Parameter Specification

Seek time (including settle) 1 cylinder: 1 ms; average: 7 ms; maximum: 15 msRotational speed 7,500 RPM (R = 8 ms)Sector size 500 bytesNumber of sectors per track 330 on average, varies with the zoneNumber of tracks per cylinder 10Number of cylinders 10,000Disk capacity 16 GbytesTransfer rate 20 Mbytes per second, sustained

66 Computer

troller. Because it produces the smallest average seekdistance, the elevator algorithm creates the bestopportunity for reducing access time through the diskcontroller’s command reordering.

If deadlines or priorities are not a consideration,how does the system prevent glitches? It does so bymonitoring the terminals to determine when theymove into a danger zone close to starvation (like awarning light on an automobile gas gauge). For exam-ple, if the unconsumed data in a terminal’s bufferdecreases below 10 percent capacity, the terminal canalert the server, which can refuse requests to start newmovies until the danger has passed. The terminal alsomust send a message if the buffer starves—a more seri-ous situation—or when its available data increasesabove the threshold level. An experienced developercan tune the system to determine a suitable threshold.For example, after lowering the threshold to 9 per-cent, 8 percent, and so forth until an actual starvationoccurs, the developer resets the threshold at a level atwhich starvation is sufficiently rare.

Buffering is another important design issue. In theserver, I use double buffering for each video stream. Ifthe block size is 0.5 Mbyte, for example, each streamhas 1 Mbyte of buffer space. The disk can read intoone buffer while the data in the other buffer transmitsthe data—or is waiting to transmit it—to the properterminal. If both buffers are either waiting or trans-mitting when the disk scheduler comes to this stream,the scheduler skips the stream for this round. This sit-uation often occurs when the system is not saturatedbecause a round takes far less time than each block’sconsumption time.

The video terminal also needs at least two blocksof buffer space. A buffer size of five or so blocks canprevent starvation caused by wide fluctuations in theconsumption rate or transmissions from the server. Toreceive another transmission, the terminal sends amessage to the server whenever one of its blocksbecomes exhausted.

STORAGE LAYOUT AND MAXIMUM NUMBER OF STREAMS

The file-storage layout on the disk files has a majorimpact on the maximum number of simultaneousvideo streams that the system can support. Four stor-age designs illustrate this effect.

In my prototype, the block size (b) is 0.5 Mbyte,or three tracks. Therefore, the server buffer space is1 Mbyte per stream. To keep up with the consump-tion rate, the average time for a round is b/cr, or1,000 ms. Subtracting the time for the full-stroke seekat the end of the round leaves 985 ms for readingblocks from the disk. The server presumably holds100 15-Gbyte disks, providing the capacity to store400 two-hour movies.

permitting the controller to optimize the tasks. The conventional two-way elevator algorithm has

the disadvantage of lengthening the maximum timebetween successive reads, especially for videos storednear the outermost or innermost cylinders. Using OE,the full-stroke seek at the end of each round exacts amodest price for the advantage of serving the streamsin round-robin order. Data blocks of 0.5 Mbyte con-sume an average of 1 second; thus, if the round timeis 1 second or less, the server can keep up with con-sumption. Assuming 0.5-Mbyte blocks, because oursample disk has a 15-ms maximum seek time, the full-stroke return seek operation uses only 1.5 percent ofa round’s allowable time.

Using elaborate scheduling policies involving dead-lines, priorities, prefetching, seek time, and latenciesis neither necessary nor desirable. Combining OE withdisk-controller optimization maximizes the disk sys-tem’s performance because minimizing seek andlatency times maximizes the number of streams thesystem can serve. Deviating from the OE sequence—to serve an earlier deadline, for example—contributesnothing to the performance if the server would havemet all deadlines anyway. Such a deviation generallyincreases the overall time for the round by increasingseek time and reducing optimization by the disk con-

1

7

23456

Full-stroke seek

Seeks

Figure 1. One-way elevator algorithm. With this schedulingalgorithm, the disk controller minimizes seeking and usescommand reordering to improve the video-on-demandsystem’s performance. In every round, each disk reading pro-ceeds at the disk controller’s discretion approximately fromthe outermost cylinder to the innermost cylinder needing tobe read. A full-stroke seek returns to the outermost cylinderneeding to be read in anticipation of the next round.

May 2001 67

Design 1—independent disk storageIndependent disks store four movies per disk, with

no striping or interleaving, as Table 3 shows. RunningOE independently on each disk provides the follow-ing values: g is m is 100, k is 1; r is 1/2 R is 4 ms; ttis b/tr, which is 0.5 Mbyte/20 Mbytes per second, or25 ms.

Although precisely determining the average seektime (s) is difficult, we can make an estimate that isaccurate enough to meet our needs. To determine themaximum number of video streams a terminal canserve, we narrow the range by considering the effectof s on the maximum. With even a few streams, wecan set an upper bound on s at the average seek time,7 ms, which usually corresponds with seeking overabout one-third of the 10,000 cylinders. Using thisvalue, we obtain the following:

a = s + r + tt = (7 + 4 + 25) ms = 36 ms ng = 985 ms/36 ms = 27 streams

Thus, 27 is a lower bound on ng.Looking at the other extreme, let’s suppose we can

ignore seek time, giving us s as 0. Then, a is 29 ms andng is 985 ms/29 ms, or 34. Therefore, 34 is an upperbound on ng.

If ng is between 27 and 34, the average seek movesover about one-thirtieth of the cylinders. Hence, amore appropriate value for s is between the one-cylin-der seek time, 1 ms, and the time to seek over one-third of the cylinders, 7 ms, but closer to the former.Using linear interpolation with these values,

we get s = 1.6 ms. Although we cannot exactly jus-tify using linear interpolation for modeling the seekmotion, using it is sufficient to approximate that s is2 ms. This gives the values a is 31 ms and ng is 32.

Because the disks operate independently, the totalnumber of supportable streams is

n = g × ng = 100 × 32 = 3,200

The theoretical limit on the number of supportablestreams, assuming zero seek and latency, is

nlim = m × tr/cr = 100 × 20 Mbytes per second/0.5 Mbyte per second = 4,000

Therefore, this design achieves 80 percent of the theo-retical limit.

Unfortunately, the design has a serious flaw—theoverall maximum is achieved only if all streams are

s − 1 ms (7 − 1) ms=130

13

evenly distributed among the 100 disks. Becausemovie popularity is highly nonuniform, expecting suchan even distribution is not realistic.

Pairing a very popular movie with an unpopularmovie on the same disk does not balance the work-load, and it isn’t practical because movie popularitychanges rapidly. For example, if a particular movieconsumes 20 percent of 3,200 requests, the disk stor-ing that movie can accommodate only 32 requests forthat movie, even if no customers submit requests forthe other three movies stored on that disk.

One option is to store multiple copies of popularmovies on different disks, which requires more diskspace. Another alternative is to require a new user tochoose a different movie if the server can’t providethe first selection—an accepted practice in a conven-tional video rental store. Our challenge, however, isto design a product that satisfies customers under allcircumstances.

Design 2—striping over disksI suggest striping each movie over all disks, as Table

4 shows. Table 4 shows that g is 1 and k is m, whichis 100. Further, ss is b/k and thus 0.5 Mbyte/100,which is 5 Kbytes or about one-thirtieth of a track.Thus, r is 4 ms, tt is ss/tr, which is 5 Kbytes/(20 Mbytesper second), which is 0.25 ms.

Using a process similar to the one used in Design 1,we initially set s as 7 ms and get these results:

a = (7 + 4 + 0.25) ms = 11.25 ms ng = 985 ms/11.25 ms = 88

Since there are at least 88 streams in a busy sys-tem, a more appropriate value for s would be 2 ms,which gives a as 6.25 ms and ng as 158. This suggeststhat we should further reduce s to 1 ms, giving a as5.25 ms and ng as 985 ms/5.25 ms, which is 188.Even setting s to 0 only yields ng = 985 ms/4.25 ms,which is 232.

Admittedly, we have not determined a precise value

Table 4. Design 2—striping over disks.

Disk 1 Disk 2 … Disk 100

Movie 1 Block 1, Seg. 1 Block 1, Seg. 2 … Blk. 1, Seg. 100Movie 1 Block 2, Seg. 1 Block 2, Seg. 2 … Blk. 2, Seg. 100Movie 1 …

…Movie 400 Block 1, Seg. 1 Block 1, Seg. 2 … Blk. 1, Seg. 100Movie 400 Block 2, Seg. 1 Block 2, Seg. 2 … Blk. 2, Seg. 100Movie 400 …

Table 3. Design 1—independent disk storage.

Disk 1 Disk 2 … Disk 100

Movie 1 Movie 5 … Movie 397Movie 2 Movie 6 … Movie 398Movie 3 Movie 7 … Movie 399Movie 4 Movie 8 … Movie 400

68 Computer

for s, but doing so is not necessary to demonstrate thatthis design is inefficient. We have

n = g × ng = 1 × ng

which is at most 232 and probably closer to 188 oreven 158. It is true that the workload is distributedevenly among all the disks and that transfer time isreduced by a factor of m equals 100. Unfortunately,parallelism benefits apply only to the transfer time andnot to seek and latency because every disk incurs aseek and latency for every stream during every round.

Design 3—striping over a groupCombining Designs 1 and 2, we divide the set of

disks into several independent groups, assign eachmovie file to one group, and then stripe each file overall the disks in its group, as Table 5 shows. Thisapproach combines the advantages of Design 1, par-allelism, and Design 2, load balancing.

Accordingly, we set g as 10 and get k as m/g, whichis 10, and ss as 50 Kbytes or about one-third of a track.Further, we get r as 4 ms and tt as 2.5 ms. Approxi-mating s as 2 ms, we get a as 8.5 ms, ng as 116, and nas 1,160. Although this is only about one-third asmany streams as Design 1’s theoretical maximum, itbalances the workload over all the groups.

Achieving this balance requires using projecteddemands for each movie and combining popular

movies with unpopular movies so that each group con-tains movies with a composite demand of approxi-mately 1/g times the total movie demand. This balancewould not be possible even theoretically if a singlemovie’s demand share exceeds 1/g. Further, this tech-nique faces serious problems relating to the reliabilityof demand estimates and the need to shift movie filesamong the groups (hourly, weekly, monthly) as moviepopularity changes.

Design 4—interleaving over all disks, with delayed startBoth interleaving and striping distribute a file reg-

ularly over multiple disks, but reading an interleavedfile is different from reading a striped file.4 Stripingsynchronizes all disks in their seek, latency, and trans-fer. The logical block read during one access is the con-catenation of the individual stripe blocks from eachdisk. Using Design 2 as an example, the striping fac-tor is m as 100, the logical block size is b as 0.5 Mbyte,and the stripe size is 5 Kbytes.

Interleaving stores the entire block on only one disk,but the system stores successive blocks in a file on suc-cessive disks in the interleave sequence, as Table 6 shows.Thus, successive accesses to service a stream are storedon successive disks, with each access reading one blockfrom a single disk.

We therefore have g as m or 100, k as 1, ss as 0.5Mbyte or three tracks, r as 4 ms, and tt as 25 ms.Approximating s as 2 ms, a is 31 ms, ng is 32, and nis 3,200, as in Design 1. Design 4 does not have Design1’s unbalanced workload liability because it inter-leaves all movies over all disks; the system either startsthe streams at relatively random times or randomizesthe starting disks for the different movies. Hence, theaverage number of streams that each disk serves dur-ing each round equals the total number of streamsdivided by the number of disks, evenly distributing theworkload regardless of movie popularity.

Despite this uniform distribution, random fluctua-tion can cause some disks to be busier than others dur-ing a round. For example, if there are 2,670 streams,the average number of accesses to each disk during

Table 5. Design 3—striping over a group.

Group 1 Group 10Disk 1 … Disk 10 … Disk 91 … Disk 100

Movie 1 B1, S1 … B1, S10 Movie 361 B1, S1 … B1, S10Movie 1 B2, S1 … B2, S10 Movie 361 B2, S1 … B2, S10Movie 1 … Movie 361 …

… …Movie 40 B1, S1 … B1, S10 Movie 400 B1, S1 … B1, S1Movie 40 B2, S1 … B2, S10 Movie 400 B2, S1 … B2, S10Movie 40 … Movie 400 …

Table 6. Design 4—interleaving over all disks, with delayed start.

Disk 1 Disk 2 … Disk 100

Block 1 Block 2 … Block 100Movie 1 Block 101 Block 102 … Block 200

……

Block 1 Block 2 … Block 100Movie 400 Block 101 Block 102 … Block 200

…

May 2001 69

each round is 26.7. One disk can have 32 accesses dur-ing a particular round, while another disk has only 23accesses. The maximum number of streams—not theaverage number—per disk during a round limits over-all system performance. The number of streams eachdisk serves during a round has the equiprobabilitymultinomial distribution. Herbert David9 has givenbounds for order statistics probabilities—for exam-ple, the busiest disk.

Fortunately, slightly delaying the start of each newstream reduces or eliminates this potential inefficiency.The stream’s starting block is read during a round whenthe disk containing the starting block is serving the min-imal number of all disks’ streams. The server can send asuitably timed graphic, music, commercial, or movie pre-view to the terminal during the wait. It can also recordthe number of streams for each disk for each round, thenchoose an appropriate starting round for the new stream.In the worst case, the delay would be m − 1 rounds. Forexample, if m is 100 and a round is 1 second, the maxi-mum delay would be about 100 seconds.

Ideally, the difference between the maximum andminimum number of streams the various disks serviceduring any round is at most one. For example, with2,670 streams, 70 disks can serve 27 streams duringa round, and 30 disks can serve 26 streams.

From its most important features, Design 4 earnsthe designation OEID—one-way elevator with inter-leaving and delayed start.

EFFECTS OF CHANGING PARAMETERSWorking with specific hardware and design para-

meters provides a context for producing realistic sys-tems using current technology. For most parameters,there is a range of realistic values. Moreover, techno-logical advances continue to cause these ranges tomove. Would different realistic sets of parameterspoint toward a different optimal design, or would thesame basic design still be the best?

Let’s consider the effects of varying the followingdesign parameters: block size, group size, number andlength of movies, disk capacity, number of disks, anddesired number of supportable users. Although otherparameter values do affect system performance, theydo not affect the relative performance of the fourdesigns.

Block sizeEnlarging the block size improves system performance

by reducing the number of seeks required to read anentire movie file. On the negative side, it increases theRAM requirements for buffers, creating a classical trade-off between performance and cost. (Making the blocksize smaller has the opposite effect.) For example, dou-bling b to 1 Mbyte has the following approximate effects:a is 56 ms, ng is 35, n is 3,500, and the buffer requirement

is 7 Gbytes. Figure 2 shows the effect of block size onbuffer requirements and the maximum number of videostreams. Adjusting the buffer size does not remedy theproblems associated with Designs 1, 2, and 3.

Striping group sizeWith striping, the choice of group size is important,

as Designs 2 and 3 show, with k as 100 and 10, respec-tively. While striping increases parallelism in transfers,it loses parallelism in seeks and latencies. In additionto increasing the transfer rate, striping permits work-load balancing among groups. A good general policyis to use the smallest group size that permits workloadbalancing. This plan depends on the accuracy ofmovie-frequency projections, and it requires movingfiles among groups as frequencies change. Further-more, even if k is optimized and the projected fre-quencies are accurate, striping’s performance is stillinferior to OEID performance.

Number of moviesThe number and length of movies a system offers

determine the total disk-space requirements. Myexample assumes 400 movies at about 4 Gbytes per

0 0.5 1Block size (Mbytes)

1.5 2

2

4

6

8

10

12

Gb

ytes

0 0.5 1Block size (Mbytes)

1.5 2

500

1,000

1,500

2,000

2,500

3,000

3,500

4,000

Nu

mb

er o

f st

ream

s

(a)

(b)

Figure 2. Effect of block size on (a) the maximum number ofsupportable video streams and (b) the total buffer require-ments. Increasing the block size improves performance byreducing the number of seeks the video-on-demand systemrequires to read an entire movie file.

70 Computer

movie, stored on 100 disks with about 16-Gbytecapacity per disk. A VoD system that offers 800movies can use 200 16-Gbyte disks, 100 32-Gbytedisks, and so forth. This parameter does not alter thechoice of optimal design.

Number of supportable movie streamsOnce a prospective VoD provider decides to offer a

certain size of movie selection and determines the totaldisk-space requirements, the question is how to con-figure the system to support the maximum numbers(n) of simultaneous users. Once the developers deter-mine the hardware and design parameters (for exam-ple, seek times, transfer rate, block size, and total diskcapacity), except for the individual disk capacity andthe number of disks, the next step is to determine thenumber ng of users each disk can support using OEID.Denoting the capacity of each disk as d and the totaldisk capacity as td, we get m = n/ng and d = td/m. Forexample, if td is 1,600 Gbytes, n is 8,000, and ng is32, we get m is 250 and d is 6.4 Gbytes.

Conforming to hardware constraints requires someadjustments. For example, if the smallest disk capac-ity is 8 Gbytes, the designer can

• use 250 disks and offer a larger selection ofmovies (520 at 4 Gbytes each);

• reduce the number of disks to 200, thereby reduc-ing the maximum number of simultaneous usersto 6,400;

• use disks with a higher transfer rate;• use a larger block size and more RAM for buffer-

ing, although this solution would be insufficientin some cases; or

• leave some disk space idle.

Note that using larger-capacity disks facilitates anincreased selection of movies but does not augmentthe number of supportable streams.10

Table 7 summarizes the storage-layout performancefor Designs 2, 3, and 4. The summary excludes Design1 because of its dependency on a uniform demanddistribution.

The optimal design for an efficient VoD systemincludes the scheduling algorithm, buffer policy,file-storage layout, and a feedback mechanism

for denying new requests when the system becomesnearly saturated. OEID’s system design includes aone-way elevator algorithm for each disk for eachround and provides double buffering for each videostream. Other features include interleaved movie filestorage, slightly delayed starts, as necessary to main-tain even workload distribution, and a warning mes-sage from the terminal when it is nearing starvation.Interleaving with delayed start is the optimal strat-egy for storing movie files on disks because it permitsmaximum overlap of the read operations—seek,latency, and transfer—over all disks, whereas stripingoverlaps only the transfer component. In addition,OEID permits an almost perfectly balanced work-load over all disks, on every round, regardless ofmovie popularity. ✸

References1. D. Le Gall, “MPEG: A Video Compression Standard for

Multimedia Applications,” Comm. ACM, Apr. 1991,pp. 47-58.

2. C. Freedman and D. DeWitt, “The SPIFFI ScalableVideo-on-Demand System,” Proc. ACM Sigmod 95,ACM Press, New York, 1995, pp. 352-363.

3. P. Yu, M. Chen, and D. Kandlur, “Design and Analysisof a Grouped Sweeping Scheme for Multimedia StorageManagement,” Proc. 3rd Ann. Workshop Network andOperating Systems Support for Digital Audio and Video,Springer-Verlag, New York, 1992, pp. 44-55.

4. D. Gemmell et al., “Multimedia Storage Servers: A Tuto-rial,” Computer, May 1995, pp. 40-49.

5. A. Reddy and J. Wyllie, “I/O Issues in a Multimedia Sys-tem,” Computer, Mar. 1994, pp. 69-74.

6. Y. Romboyannakis et al., “Disk Scheduling for Mixed-Media Workloads in a Multimedia Server,” Proc. ACMMultimedia 98, ACM Press, New York, 1998, Session 7S, paper S-118.

7. Maxtor Corp., http://www.maxtor.com/Maxtorhome.htm, Apr. 2001.

8. C. Ruemmler and J. Wilkes, “An Introduction to DiskDrive Modeling,” Computer, Mar. 1994, pp. 17-28.

9. H. David, Order Statistics, John Wiley & Sons, NewYork, 1970, pp. 87-88.

10. S. Ng, “Advances in Disk Technology: PerformanceIssues,” Computer, May 1998, pp. 75-81.

William E. Wright is professor and chair of theDepartment of Computer Science at Southern IllinoisUniversity at Carbondale. His research interestsinclude video-on-demand systems, file organization,data structures, graphics, and cluster analysis. Wrightreceived a DSc in applied mathematics and computerscience from Washington University, St. Louis. Con-tact him at wright@cs.siu.edu.

Table 7. Storage-layout performance.

Design Description Maximum number of streams

2 Striping over all disks 1883 Striping over a group 1,1604 Interleaving 3,200