Reducing I/O Demand in Video-On-Demand Storage Servers. from being transmitted directly from tertiary devices.

Transcription

1 Reducng I/O Demand n Vdeo-On-Demand Storage Servers Leana Golubchk y John C.S. Lu z Rchard Muntz x Abstract Recent technologcal advances have made multmeda on-demand servces, such as home entertanment and home-shoppng, mportant to the consumer market. One of the most challengng aspects of ths type of servce s provdng access ether nstantaneously or wthn a small and reasonable latency upon request. In ths paper, we dscuss a novel approach, termed adaptve pggybackng, whch can be used to provde on-demand or nearly-on-demand servce and at the same tme reduce the I/O demand on the multmeda storage server. 1 Introducton Recent technologcal advances n nformaton and communcaton technologes have made multmeda on-demand servces, such as moves-on-demand, home-shoppng, etc., feasble. Informaton systems today can not only store and retreve large multmeda objects, but they can also meet the strngent real-tme requrements of contnuously provdng objects at a constant bandwdth, for the entre duraton of that object's dsplay. Already, multmeda systems play a major role n educatonal applcatons, entertanment technology, and lbrary nformaton system. In ths paper, we consder a vdeo-on-demand storage server, e.g., as the one depcted n Fgure 1, whch archves many objects of long duraton, such as moves, musc vdeos, educatonal tranng materal, etc. The storage server conssts of a set of dsks (D1 : : : D N ), a set of processors (N1 : : : N K), buer space, and a tertary storage devce. The entre database resdes on tertary storage, and the more frequently accessed objects are cached on dsks 1. We assume that a request for an object must be servced from the dsk sub-system; the sze of the objects (on the order of 4:5 GB for a 100 mnute MPEG-2 encoded move) precludes them from beng stored n man memory, and the long latency Appeared n SIGMETRICS/Performance '95 y Computer Scence Department, UCLA (leana@cs.ucla.edu). Ths research was supported n part by the NSF graduate fellowshp and the IBM graduate fellowshp. z Department of Computer Scence, The Chnese Unversty of Hong Kong (cslu@cs.cuhk.hk). Ths research was supported n part by the CUHK Drect Grant and the Croucher Foundaton. x Computer Scence Department, UCLA (muntz@cs.ucla.edu). Ths research was supported n part by Hewlett Packard through an equpment grant. 1 We assume that the cachng on dsks s done on-demand,.e., a non-dsk resdent object s fetched from tertary storage only when t s referenced; some form of the LRU polcy can be used to purge objects from dsks (n order to create space for the newly retreved object). TV D 1 D 2 HDTV buffer space N 1 Network N K T1 T2 T3 D N multmeda storage server dsplay statons Fgure 1: Multmeda Storage Server Archtecture. and hgh bandwdth cost of tertary storage 2 precludes objects from beng transmtted drectly from tertary devces. If the requested object s not dsk-resdent, then t has to be retreved from the tertary store and placed on dsks before ts dsplay can be ntated; ths could result n one or more objects beng purged from dsks, due to lack of space. A dsk resdent object s dsplayed by schedulng an I/O stream and readng the data from the approprate dsks. One of the most challengng aspects of such systems s provdng on-demand servce to multple clents smultaneously, thus realzng economes of scale; that s, users expect to access objects, e.g., moves, wthn a small and \reasonable" latency, upon request. We dene the latency for servcng a request as the tme between the request's arrval to the tme the system ntates the readng of the object (from a dsk); the addtonal delay untl data s actually delvered to the dsplay devce s consdered relatvely neglgble. Latency can be attrbuted to: a) nsucent bandwdth for servcng the request, b) nsucent buer space for schedulng ts readng from the dsks, or c) nsucent dsk storage,.e., the object n queston may not be dsk-resdent and hence may have to be retreved from tertary storage before t can 2 The seek latency for a 1:3GB tape on a $1000 tape drve can be on the order of 20 seconds [7], whereas a smlarly prced dsk, of a smlar capacty, has a maxmum seek tme on the order of 35 mllseconds and more than 16 tmes the transfer rate. Tape systems wth sgncantly hgher transfer rates and tape capactes although not wth much lower seek latency do exst, but at a cost $40;000- $300; 000.

2 be scheduled for dsplay. For ease of exposton, we can assume that the server, depcted n Fgure 1, can be descrbed by the followng three parameters: 1) total avalable I/O bandwdth, 2) total avalable dsk storage space, and 3) total avalable buer space 3. These parameters, n conjuncton wth data layout and schedulng schemes, determne the cost of the server as well as the \qualty of servce" t can oer; although qualty of servce s a somewhat ambguous term, the latency, n servcng a vdeo request, s one useful measure. In general, the more vdeo streams a system can support smultaneously, the lower s the average latency for startng the servce of a new request (at least for the dsk resdent objects). There are several basc archtectures that can be used for constructng a vdeo-on-demand server [1, 14, 11]. The dstnctons between these archtectures can be (mostly) attrbuted to the data layout and schedulng technques used. Let us consder one such system, where the workload can be descrbed by = (1; 2; : : : ; K), where s the arrval rate of requests for object and K s the total number of objects avalable on the storage server (ncludng the nondsk-resdent objects). Informally, we expect a skewed dstrbuton of access frequences wth a relatvely small subset of objects accessed very frequently, and the rest of the objects exhbtng farly small access rates 4. In such a system, t s far to assume that there s sucent dsk storage to at least hold the popular objects; moreover, t s very lkely that I/O bandwdth s the crtcal resource whch contrbutes to ncreases n latency. One way to reduce the latency s to smply purchase more dsks. A more nterestng and more economcal approach mght be to ether attempt to mprove the data layout and schedulng technques or to reduce the I/O demand of each request n servce through \sharng" of data between requests for the same object. There are several approaches to reducng the I/O demand on the storage server through sharng, or, n eect, ncreasng the number of user requests whch can be served smultaneously. For example: 1. batchng: delayng requests for up to T tme unts n hopes of more requests, for the same object, arrvng durng the batchng nterval and servcng the entre group usng a sngle I/O stream 2. brdgng: closng the temporal \gaps" between successve requests through the use of buer space,.e., holdng data read for a \leadng" stream and servcng \tralng" requests out of the buer rather than by ssung another I/O stream 3. adaptve pggybackng: adjustng dsplay rates of requests n progress (for the same object) untl ther correspondng I/O streams can be \merged" nto one In ths paper we concentrate on adaptve pggybackng. It s a more nnovatve approach and, to the best of our knowledge, has not been studed (or even proposed) before. Some work on batchng [4] and brdgng [9] does exst. An adaptve pggybackng procedure s dened to be a polcy for alterng dsplay rates of requests n progress (for the 3 We wll not consder the characterstcs of the tertary devce n ths paper. 4 For nstance, a move server would have such characterstcs, where a small subset of popular moves (for that week, perhaps) s accessed smultaneously by relatvely many users; furthermore, we assume that the change n access frequency s relatvely slow, e.g., the set of popular moves should not change more often than once per week. new arrvals k Fgure 2: Conveyor Belt Analogy. same object), for the purpose of mergng ther respectve I/O streams nto a sngle stream, whch can serve the entre group (of merged requests). The dea s smlar to that of batchng, wth one notable excepton. The groupng s done dynamcally and whle the dsplays are n progress,.e., no latency s experenced by the user. Note that, the reducton n the I/O demand s not qute as hgh as n the case of batchng, snce some tme must pass before the streams can merge 5 ; hence, the tradeo (between these two technques) s between latency for startng the servce of a request and the amount of I/O bandwdth saved. Note also that, these technques are not mutually exclusve; n ths paper, we present results of usng adaptve pggybackng n conjuncton wth batchng. Consder an analogy of servcng vdeo requests, for a partcular move, to a collecton of bugs sttng on a movng conveyor belt (refer to Fgure 2). The conveyor belt repj departures resents one partcular move; ts length corresponds to the duraton of the move's dsplay, and the rate at whch the conveyor moves corresponds to the normal dsplay rate of the move (e.g., 30 frames/sec for U.S. televson). Each bug represents a sngle I/O stream, servcng one or (as we shall see later) more dsplay requests for that move; the poston of the bug on the conveyor belt represents the part of the move beng dsplayed by the correspondng I/O stream. If a bug chooses to reman stll on the conveyor belt, then the correspondng stream dsplays the move at the normal rate. If the bug chooses to crawl forward (at some speed), then the correspondng move s dsplayed at a slghtly hgher rate. Smlarly, f the bug chooses to crawl backwards (at some speed), then the correspondng move s dsplayed at a slghtly lower rate. We elaborate on the techncaltes nvolved n alterng dsplay rates (wthn the bounds not perceptble by a human observer) n Secton 2; for the remander of ths secton we assume that t can be done and concentrate on the (possble) benets of ths approach. These benets are as follows; f two bugs, one crawlng forward and one crawlng backward, are able to \merge" at tme t, before ether one falls o the conveyor belt, then startng at tme t the system s able to support both dsplays usng only a sngle I/O stream 6. Consder for the moment bug n Fgure 2, whch must make a decson, namely, whether to crawl forward, toward bug j, 5 The dsplay adjustment must be gradual (or slow) enough to nsure that t s not notceable to the user; we assume that alterng the qualty of the dsplay (as perceved by an \average" user) s not an acceptable soluton. 6 Clearly, there s a problem of provdng VCR functonalty; A smlar problem was solved n the context of batchng n [4, 6], and ther soluton of reservng channels for ths purpose, can be used here as well; furthermore, adaptve pggybackng has one addtonal benet. After obtanng reserved channel and resumng dsplay, further attempts at mergng can be made; f successful, the reserved channel can be returned and reused by another stream.

3 and pggyback on ts I/O stream or whether to crawl backward, toward bug k, and nstead pggyback on ts stream. If crawls forward, then t wll take less tme to merge; however, after the merge, a smaller porton of the move wll reman (to be dsplayed), and hence the benets of mergng would not be as great. On the other hand, f crawls backward, toward k, then t wll take longer to merge; however, greater benets mght be reaped from that merger, f t can be acheved at an earler porton of the conveyor belt. In ths paper, we consder several mergng polces and evaluate them wth respect to reducton n I/O bandwdth utlzaton. In general, the followng parameters can be used to mprove the number of smultaneous requests that a system can serve: 1) delay tme (for batchng), 2) mergng polcy (for adaptve pggybackng), 3) buer allocaton polcy, and 4) dsplay rate alterng technques (see Secton 2 for more detals). Reducton n the I/O bandwdth consumed by the aggregate requests for a move s consdered to be the man goal of these polces. Whle other resources are aected, dsk bandwdth s lkely to be the most mportant and costly. Ths wll reman so for the foreseeable future snce dsk capacty s ncreasng at a faster rate than dsk bandwdth. The remander of the paper s organzed as follows. In Secton 2, we descrbe the feasblty of supportng multple dsplay rates. In Secton 3, we brey state the batchng polcy assumed n the remander of ths paper. In Secton 4, we descrbe several adaptve pggybackng polces. Performance analyss of these polces can be found n Secton 5, and the dscusson of results can be found n Secton 6. Our conclusons and drectons for future work are gven n Secton 7. 2 Alterng Vdeo Dsplay Rates As stated n Secton 1, adaptve pggybackng s a vable technque for reducng I/O demand on a vdeo storage server (and consequently mprovng the response tme of the system), f the storage server has the capablty to dynamcally alter the dsplay rate of a request, or, rather, to dynamcally tme compress or tme expand some porton of an object's dsplay 7. In ths secton we dscuss how ths can be done. We make the basc assumpton that the dsplay unts beng fed by the storage server are NTSC standard and dsplay at a rate of 30 frames per second (fps). Therefore any tme expanson or contracton must be done at the storage server. Slow down n the eectve dsplay rate can be done by addng addtonal frames to the vdeo snce the dsplay devce dsplays at a xed rate. For example, f 1 addtonal frame s added for every 10 of the orgnal frames, the eectve dsplay rate (org-frames/sec) wll be Smlarly, by removng frames the eectve dsplay rate can be ncreased. There s ample evdence that eectve dsplay rates that are 5% of the nomnal rate can be acheved n such a way that t s not percevable by the vewer. For example: A move shot on lm s transferred to vdeo usng a telecne machne whch adapts to the 30 fps requred for the vdeo from the 24 fps whch s standard for lms; ths s done usng a 3-2 pulldown algorthm [12, 10], whch for every 4 move frames creates 5 vdeo 7 We do not dscuss t n detal here, but necessary tme adjustments can be performed on the audo porton of an object, usng technques such as audo ptch correcton [2]; clearly, the rate of ths adjustment must be chosen accordngly to nsure the necessary synchronzaton [12] wth the vdeo porton of the object. frames, where two of the ve frames produced are nterpolatons of a par of the orgnal frames. A smlar type of nterpolaton could be used n our applcaton. Ampex makes a product called Zeus(TM) [5] whch can be used to produce hgh qualty vdeo that has been tme compressed or expanded by up to 8%; accordng to the product lterature t can accomplsh ths wthout bounce or blur. Personal contacts wthn the the vdeo edtng ndustry have assured us alteratons of the actual dsplay rate n the 2? 3% range [3] or expanson and contracton (through nterpolaton) n the 8% range [2] can be accomplshed wthout beng notceable to the vewer. There are two approaches to actually provdng the altered stream of frames to be transmtted to the dsplay statons. The altered verson of the vdeo can be created onlne. In ths case the I/O bandwdth requred from the dsk vares wth the eectve dsplay rate. There are two possble dsadvantages of the on-lne alteraton: (1) the layout of the data on dsk s often tuned to one delvery bandwdth and havng to support multple bandwdths can complcate schedulng and/or requre addtonal buer storage and (2) to support on the y modcaton may requre the expense of specalzed hardware to keep up wth the demand. The altered verson of the vdeo s created o-lne and stored on dsk wth the orgnal verson. The obvous dsadvantage of ths approach s the addtonal dsk storage requred. Based on the above dscusson, we wll, n the remander of ths paper, assume that we can alter the eectve dsplay rate by 5% wthout sacrcng vdeo qualty, and we wll consder both the on-lne generaton approach to provdng the altered stream of frames and the o-lne approach 8 For the latter, we wll nclude addtonal consderatons n the schedulng polces that are motvated by the desre to lmt the amount of addtonal dsk space requred for storng replcates of a vdeo. 3 Batchng As already mentoned n Secton 1, one way to reduce the I/O demand (Mb/s) on the storage server s to batch requests, for the same object, nto a sngle I/O request to the storage server. The tradeo for the batchng approach s the amount of latency experenced by a request versus the correspondng reducton n I/O demand on the storage server. In ths paper, we concentrate on controllng utlzaton, and more speccally, on controllng utlzaton of the I/O subsystem; for reasonably busy systems (the only really nterestng case), the lower utlzaton a system has, the lower s ts response tme for servcng requests. There are several ways to batch requests nto a sngle I/O stream. Due to space lmtatons we do not dscuss batchng polces here and n the remander of the paper assume that the batchng by tmeout polcy (see [8]) s used, 8 In ether case we assume that when frames are nserted, the addtonal frames are some nterpolaton of exstng frames (not smply duplcates). Smlarly, when a frame s deleted, the precedng and succeedng frames are altered to reduce the abruptness of the change (e.g., each becomes an nterpolaton of the orgnal and the deleted frame).

4 whch can brey be descrbed as follows. The tmer s set when a request arrves to the storage server and there exsts no other outstandng request for the same object j. The system ssues an I/O request to the storage server T j tme unts after the ntaton of the tmer. Any request, for the same object, arrvng durng these T j tme unts s batched and servced when the tmer expres. Assumng that the request arrval process, for a partcular object j, s Posson wth rate j, we can vew the system as an M=G=1 queue wth a constant setup tme (where the setup tme s the duraton of the tmer T j) and a determnstc servce tme dstrbuton wth a mean of zero. The expected latency for ths type of a system can be found n [13] as: E[L j] = Tj(2 jtj) 2(1 jt j) 4 Adaptve Pggybackng In ths secton, we descrbe several adaptve pggybackng polces. Consder a storage system, where for each request for an object there exsts a dsplay stream and a correspondng I/O stream. The processng nodes use the I/O streams to retreve the necessary data from dsks, possbly modfy the data n some manner, and then use the dsplay streams to transmt the data (through the network) to approprate dsplay statons (e.g., n Fgure 3, dsplay streams 1 and 2 are servced usng the correspondng I/O streams 1 and 2). The I/O demand on the storage server can be reduced by I/O stream 1 Processng Nodes I/O stream 2 Dsk Sub-system I/O stream 3 dsplay stream 1 dsplay stream 2 dsplay stream 3 dsplay stream 4 Network dsplay statons I/O stream 1 dsplay stream 1 I/O stream 2 dsplay stream 2 I/O stream 3 dsplay stream 3 dsplay stream 4 Fgure 3: Smpled Vew of the System. usng a sngle I/O stream to servce several dsplay streams correspondng to requests for the same object (e.g, n Fgure 3, dsplay streams 3 and 4 correspond to requests for the same object and are servced usng a sngle I/O stream 9, 3. As stated n Secton 1, ths can be done n a statc manner,.e., by batchng requests (see Secton 3), and n a dynamc or adaptve manner; adaptve pggybackng s the topc of ths secton. A dynamc approach ntates an I/O stream, for each dsplay stream, on-demand, and then allows one dsplay 9 Dependng on the network characterstcs, t mght be wser to delay \splttng" dsplay streams 3 and 4 untl the last possble moment,.e., transmt them through the network as a sngle stream for as long as possble. However, we do not consder network characterstcs n ths paper,.e., we assume that there s sucent bandwdth avalable n the network; hence, we shall not consder alternatve transmsson polces here whch can reduce network bandwdth utlzaton. (1) stream to adaptvely pggyback on the I/O stream of another dsplay stream (for the same object). We can also vew ths as a dynamc mergng of two I/O streams nto one. Before the merge, there were two I/O streams, each servng one (or more) dsplay stream(s), where the dsplay streams correspond to two temporally separated dsplays of the same object. After the merge, there s only one I/O stream, whch can servce both dsplay streams, and furthermore the correspondng dsplays are then \n synch". As descrbed n Secton 1, ths mergng can be accomplshed by adjustng requests' dsplay rates,.e., rather than dsplayng each request at the \normal" rate, the system can adjust the dsplay rate of each request (see Secton 2), ether to a \slower" rate or a \faster" rate, n order to close the temporal gap between the dsplays. Although adaptve pggybackng and batchng are not mutually exclusve technques, for ease of exposton, n ths secton we concentrate on adaptve pggybackng polces only. The results of usng adaptve pggybackng polces n conjuncton wth batchng polces are reported n Secton 6. Our goal n ths paper s to nvestgate the benets, namely, the reducton n I/O bandwdth utlzaton, attrbutable to the adaptve pggybackng rather than due to a partcular storage server archtecture. Therefore, we do not specfy data layout and/or schedulng schemes, and furthermore, we do not specfy a partcular dsplay rate alteraton technque Instead, n the followng dervaton, we assocate an I/O cost wth each I/O stream, where the cost s a functon of the correspondng dsplay rate. In other words, the I/O cost for servcng a slow- (or a fast-) rate dsplay can be derent from the I/O cost for servcng a normal-rate dsplay 10. For nstance, the speed up (or slow down) can be acheved by replcatng data (see Secton 2), n whch case, the total number of bytes read from dsks may der, dependng on the dsplay rate of a stream. If on the other hand droppng (or duplcaton) of frames s used (see Secton 2), then the total number of bytes read from dsks wll reman the same, regardless of the dsplay rate of a stream. In the followng development we do not make assumptons about whch method s used to acheve derent dsplay rates. We can vew the duraton of the object's dsplay as a contnuous lne of nte length and consder the problem of adaptve pggybackng as a decson problem; gven the global state of the system,.e., the poston (relatve to the begnnng of the dsplay) of each dsplay stream n progress, we must choose a dsplay rate for each of these requests, such that the total average I/O demand on the system s mnmzed 11 Snce mergng s only possble for I/O streams correspondng to dsplays of the same object, we can consder each group of requests for the same object, separately. For the remander of ths secton, we consder requests for a partcular object only,.e., the remander of the dscusson s n terms of a sngle object. We begn by dervng the general condtons under whch I/O streams and j can be merged n such a way as to reduce the total I/O demand on the storage server. Intally, 10 Note that, there could be other costs, other than I/O bandwdth, assocated wth readng data at hgher or lower rates, e.g., addtonal buerng space, schedulng complexty, etc.; for nstance, one mght consder usng only two alternate dsplay rates (e.g., normal and fast) to reduce the schedulng complexty. However, snce we do not consder a specc archtecture, we wll not evaluate such costs n ths paper. 11 Note that we take mnmzaton of the average I/O demand as the objectve. Such reductons, f small, would not necessarly be a good measure of how latency s decreased; however we wll show that large reductons are obtanable, and therefore the reducton n I/O bandwdth requrements wll translate drectly to latency reducton.

5 we assume that mergng can occur at any tme durng the object's dsplay; ths assumpton s removed at the end of ths secton. We dene the followng notaton for dervaton purposes (refer also to Fgure 4): S 0 k = dsplay speed (n frames/sec) of dsplay stream k f no attempt to merge s made, where k 2 f; jg. S k = adjusted dsplay speed (n frames/sec) of dsplay stream k f mergng attempts are made, where k 2 f; jg. Sk = dsplay speed (n frames/sec) of dsplay stream k after mergng, where k 2 f; jg. p M = total number of frames n a vdeo object. p k = current poston n object's dsplay (n frames) of I/O stream k, where k 2 f; jg. p m = poston (n frames) n an object's dsplay where I/O streams and j merge. C 0 k = I/O bandwdth (n bts/sec) of I/O stream correspondng to dsplay stream k, wth a dsplay speed of Sk. 0 C k = I/O bandwdth (n bts/sec) of I/O stream correspondng to dsplay stream k, wth a dsplay speed of S k. Ck = I/O bandwdth (n bts/sec) of I/O stream correspondng to dsplay stream k, wth a dsplay speed of Sk. d = dstance (n frames) between I/O streams and j, whch s equal to p j? p. d m = dstance (n frames) between the merge pont and the current poston of j, whch s equal to p m?pj. S 0 p p p p j m M d S j j d m W p (p ) Fgure 4: State of the system. Fgure 4 represents the duraton of an object's dsplay as a contnuous lne of length p M. Each dsplay stream, e.g., stream, s dented by t's poston n the object's dsplay, p, and s movng at a partcular dsplay speed, S. In order to merge I/O streams and j, rstly, we have to nsure that S > S j. Secondly, we can dene the followng dstance and cost constrants whch can be used, n any adaptve pggybackng polcy, to dentfy mergng opportuntes,.e., whether or not t s possble and cost eectve to merge I/O streams and j. The cost constrant nsures that the total I/O demand (measured n bts read from the dsk) wth mergng s less than the total I/O demand wthout mergng. Ths I/O cost constrant s as follows 12 : dc dmc S S dmcj S j (pm? p)c 0 S 0 (pm? d? dm? p)c j S j (pm? p? d)c 0 j S 0 j 12 Snce I/O stream s merged wth j, after the merge only the I/O cost of stream j need be consdered beyond the merge pont. (2) Note that ths constrant s only meanngful when the number of bts read from the dsk s not ndependent of the dsplay rate,.e., n our case t s meanngful only when replcaton s used. Otherwse, any mergng pror to the end of a dsplay results n savngs; then Equaton 3 becomes the only constrant, namely, the object length (or duraton of ts dsplay) s nte and hence requres the followng dstance constrant: Fnally, the merge tme constrant s: p d d m pm (3) d d m S = dm S j (4) Let d1 be the maxmum d such that the I/O cost condton n Equaton (2) s satsed. We obtan d1 by usng Equaton (4) to obtan d m = d Sj n Equaton (2); hence: d1 = S?S j (pm?p )C 0 (p M?p )C 0 j S 0 S 0 j C S? C j S j C0 j S 0 j and then settng the equalty? (p M?p )C j S j Sj S?S j C S C j S j? C j S j (5) Let d2 be the maxmum d such that the dstance constrant n Equaton (3) s satsed. Agan, d2 can be obtaned by substtutng the expresson for d m nto Equaton (3) and solvng for equalty: d2 = (pm? p)(s? Sj) S (6) Let d be the maxmum dstance between two I/O streams such that mergng these two streams (at d m), results n a reducton of I/O demand on the storage server. Therefore, d = mn(d1; d2) (7) We can now apply ths result to the varous adaptve pggybackng polces, whch are descrbed next. Our goal s to nd adaptve pggybackng polces whch have sgncantly lower expected I/O demand compared to that of the baselne polcy 13. We make the followng observatons about the dsplay adjustment decsons. Consder agan the system state depcton n Fgure 4; clearly, the only stochastc events n the system are the arrval ponts; such events as mergng of two streams, end of a dsplay, etc., are predctable. Hence, an optmal polcy can evaluate all possble dsplay rates, make approprate decsons wth respect to mnmzng the average system I/O demand, and then not re-evaluate these decsons untl the next arrval pont. However, ths would be computatonally ntensve and hence mpractcal. Instead, we consder a class of (smpler) polces whch make speed adjustments when one of the followng four types of events occurs: 1) arrval, 2) merge, 3) dropo, and 4) wndow crossng. An arrval event corresponds to an ntaton of a new I/O stream. A merge event corresponds to the merge of two I/O streams, and a dropo event corresponds to the end of a dsplay of an object,.e., to a \departure" of an I/O stream. A wndow crossng event refers to passng the 13 A polcy that does not use dsplay adjustment,.e., each I/O streams s dsplayed at ts normal dsplay rate.

6 boundary of a catch-up wndow, whch s llustrated n Fgure 4. We dene a catch-up wndow, W p(p ), for polcy p, to be the maxmum possble dstance between stream and stream j, ahead of stream, such that \protable" mergng s possble; W p(p ) s computed relatve to poston p n an object's dsplay; we shall see shortly how the catch-up wndow s used n the mergng polces below. W p(p ) can be computed usng Equaton 7. The sooner (n the object's dsplay) mergng occurs the more resources (e.g., dsk bandwdth, buer space, etc.) can be conserved and used by the storage system to servce other requests. Hence, n the remander of ths paper we shall assume the maxmum possble devatons from the normal speed (both for slower and faster than normal dsplay rates). In other words, we lmt our polces to consder only three possble dsplay rates: 1) the slowest rate,, 2) the normal rate,, and 3) the fastest rate, ; the correspondng I/O demands, or cost rates, are C mn, C n, and C max. 1. Baselne polcy: Ths s the normal stuaton; when requests arrve, there s no attempt to adjust the dsplay rates,.e., all requests are assgned the normal dsplay speed of and there are no mergng events n the system. (Note, that the lack of mergng does not exclude the possblty of ntal batchng.) 2. Odd-even reducton polcy: A smple dsplay rate adjustment polcy whch attempts to reduce I/O demand by at most 50% s the Odd-even reducton polcy. The basc approach s to par up (for mergng) consecutve arrvals, whenever possble; the algorthm s gven below. Let us dene W oe(0), measured relatve to the begnnng of an object's dsplay (see Fgure 5), to be the catch-up wndow for the odd-even reducton polcy. The al- new arrval d c b a 0 p M W (0) oe Fgure 5: Scenaro of Odd-even Reducton Polcy. gorthm for odd-even reducton s: Algorthm Odd-even reducton Case arrval of stream : If ((no stream, n front, s wthn W oe(0) frames) or (stream mmedately n front s movng at )) S = ; else S = ; Case merge of and j drop stream ; S j = ; Case wndow crossng, W oe(0), (by stream ) If (S == ) and (no stream behnd, n W oe(0), movng at ) S = ; else S s unchanged end Fgure 5 llustrates one possble scenaro of ths polcy. When an I/O stream d arrved to the system, I/O stream c was stll n the catch-up wndow, W oe(0), \movng" at the dsplay speed of ; n ths case, the dsplay speed of request d s set to. Lkewse, when stream b arrved to the system, I/O stream a was wthn the catch-up wndow W oe(0); therefore, the dsplay speed of b s set to. In ths scenaro, I/O streams a and b merge nto a sngle I/O stream, and streams c and d also merge nto a sngle I/O stream. W oe(0) can be computed usng Equaton (7), where the values of d1 and d2 can be found (usng Equatons (5) and (6), respectvely) by smply settng p = 0, C = C max, S =, C j = C mn, S j =, C 0 = C 0 j = C n, S 0 = S 0 j =, C = C n, S =. Then, we have: d1 = d2 =? C max Smax? pm Cn Sn? C max Smax? Smax C mn S? Cn mn Sn (8) pm (Smax? Smn) (9) 3. Smple mergng polcy: As n the case of the odd-even reducton polcy, we rst dene W sm(0) to be the catch-up wndow for the smple mergng polcy, measured relatve to begnnng of an object's dsplay (see Fgure 6). In addton, we dene W m sm(0) to be the maxmum mergng wndow for the smple mergng polcy, also measured relatve to the begnnng of an object's dsplay (see Fgure 6). W m sm(0) ndcates the latest possble poston where two streams can merge,.e., f arrves to the system and nds j W sm(0) frames ahead of t, then and j can stll merge, and moreover they wll merge at the rght-hand boundary of W m sm(0) (see Fgure 6). The basc new arrval e d c b a 0 p W M sm (0) W sm m (0) Fgure 6: Scenaro of Smple Mergng Polcy. ratonale behnd smple mergng polcy s to assgn streams to \mergng groups", where one stream, e.g., stream, ntates the group, and all streams that arrve to the system whle stream s n W sm(0), eventually merge wth stream ; the last stream wll merge \nto the group" before leavng W m sm(0). The algorthm for the smple mergng polcy s: Algorthm Smple mergng polcy Case arrval of stream : If no stream wthn W sm(0) s movng at S = ; else S = ; Case merge of and j drop stream ; S j = ; Case wndow crossng, W m sm(0) S = ; end Note that the ratonale for keepng the dsplay speed at untl crossng the rght boundary of W m sm(0) s to allow all streams n the mergng group to eventually merge.

7 Fgure 6 llustrates one possble scenaro under ths polcy. When I/O stream c arrved to the system, I/O stream a had already moved outsde of the catch-up wndow W sm(0); therefore, the dsplay speed of I/O stream c was set to. When stream b (streams d and e) arrved to the system, stream a (stream c) was wthn the catch-up wndow, W sm(0); therefore, ther dsplay speeds were set to. In ths scenaro, stream b eventually merges wth stream a, and streams d and e merge wth stream c (all merges occur wthn W m sm(0)). W sm(0) and W m sm(0), can both be computed usng Equaton (7). The values of d1 and d2 can be found (usng Equatons (5) and (6), respectvely) by smply settng p = 0, C = C max, S =, C j = C mn, S j =, C 0 = C 0 j = C n, S 0 = S 0 j =, C = C n, S =. Then, we have: and d1 =? C max Smax? pm Cn Sn? C max Smax? Smax C mn S? Cn mn Sn (10) pm (Smax? Smn) d2 = (11) W sm(0) = mn(d1; d2) (12) Wsm(0) m = W sm(0) d m = W sm(0)? Smn (13) 4. Greedy polcy: If the request arrval rate to the system s moderate to hgh, then t s advantageous to merge requests as early as possble (thereby reducng the I/O demand sooner). Both odd-even reducton and smple mergng polces attempt to accomplsh ths. But, t s stll possble to further merge I/O requests, whch have accomplshed some form of \early mergng". The greedy polcy attempts to merge I/O requests as many tmes as possble, durng the entre duraton of an object's dsplay. Therefore, n addton to the ntal catch-up wndow, W g(0), measured relatve to the begnnng of an object's dsplay, we shall also use W g(p ), a catch-up wndow measured relatve to poston p n an object's dsplay. Ths \current" catch-up wndow s used by the greedy polcy new arrval f e p c a 0 p W M g (0) W g (p ) Fgure 7: Scenaro of Greedy Mergng Polcy. (descrbed below) as an ndcaton of opportunty for further mergng. The greedy polcy works as follow. Upon arrval of a request for the object, the speed adjustment s performed as n the odd-even reducton polcy. If on crossng the catchup wndow, the stream determnes that t has not yet been pared up for mergng, then t checks W g(w g(0)), for possblty of mergng wth some stream n front. When mergng occurs at poston p, a new catch-up wndow W g(p ) s computed. If there s no I/O request wthn ths wndow, the request's speed s set to. If there are some requests wthn the catch-up wndow W g(p ) and the I/O request mmedately n front has a dsplay speed of, then that request's speed s set to and the speed of the request at poston p s set to. In algorthmc form, the greedy polcy s descrbed as follows: Algorthm Greedy Algorthm Case arrval of stream : If ((no stream, n front, s wthn W g(0) frames) or (stream mmedately n front has dsplay speed )) S = ; else S = ; Case merge of streams and j drop stream ; compute W g(p j), where p j s the poston of stream j; If ((no stream k wth speed, s mmedately n front, wthn W g(p j) frames) S j = ; else S k = ; S j = ; Case wndow crossng, W g(0), (by stream ) compute W g(p ); If ((S == ) or (S j ==, where j s stream mmedately behnd, n W g(0))) S s unchanged else If (stream k wth speed, mmedately n front, s wthn W g(p )) S k = ; S = ; else S = end Fgure 7 llustrates one possble scenaro of ths polcy. I/O streams b and d (not shown) have been already merged wth I/O streams a and c, respectvely; ths occurred n the rst catch-up wndow W g(0). After mergng of I/O streams d and c, I/O stream c attempts to merge wth I/O stream a, n catch-up wndow W g(p ). At the same tme, a newly arrved I/O stream, f, attempts to merge wth I/O stream e, whch s wthn ts catch-up wndow W g(0). W g(p ), can be derved from Equaton (7). The values of d1 and d2 (now both functons of the 's current poston,.e., p ) can be found by smply settng C = C max, S =, C j = C mn, S j =, C 0 = C 0 j = C n, S 0 = S 0 j =, C = C n, S =. Then, we have: d1 = d2 =? C max Smax? 2 (p M?p )Cn p M Cn Sn Sn? C max Smax? Smax C mn S? Cn mn Sn (14) pm (Smax? Smn) (15) Lmted Mergng At ths pont we remove the assumpton that mergng can occur at any tme. If replcaton of data s necessary n order to perform the dsplay rate alteraton (see Secton 2), then we must consder another parameter, namely, the amount of addtonal dsk space that would be necessary to store replcated data. As already mentoned, there s a tradeo between the amount of addtonal storage, necessary to replcate data, and the reducton n I/O demand that can result 14. We can evaluate the tradeo by placng an add- 14 Note that, we do not necessarly have to store three derent

8 tonal constrant on the mergng polces, namely, the constrant of a maxmum mergng pont (n the dsplay of an object). In other words, we can control the amount of data that must be replcated by allowng mergng only f t can occur wthn a speced amount of tme or rather wthn a certan dstance (n frames), from the begnnng of an object's dsplay; we refer to ths dstance as p max m. Consder agan Fgure 4 and Equatons (2)-(4) whch descrbe the dstance and cost constrants that must be met n order to attempt mergng of two dsplay streams. To control the amount of replcaton, we enforce the addtonal constrant that the merge must occur before p max m rather than before p M,.e., p m p max m. Thus, Equatons (3) and (6) are replaced by Equatons (16) and (17), respectvely, as follows: p d d m p max m (16) d2 = (pmax m? p )(S? Sj) S (17) All other equatons can reman unchanged. (Of course, these modcatons must be carred through for all the adaptve pggybackng polces descrbed above.) Results of studes of adaptve pggybackng, n conjuncton wth batchng, both wth and wthout a constrant on the maxmum mergng pont, are reported n Secton 6; performance analyss of these polces can be found n Secton 5. 5 Performance Analyss In ths secton we present analytc solutons for computng I/O demand on a storage server whch uses adaptve pggybackng polces n conjuncton wth batchng. We dene the followng notaton (also see Fgure 8) used n the dervaton of ths secton. All computaton s done wth respect to a partcular multmeda object j. Unless otherwse stated, we drop the subscrpt j for smplcty of llustraton. p M = number of frames n a move T = batchng delay tme (determnstc) = mean arrval rate t e = mean tme between the end of one batchng delay nterval and the begnnng of the next one (see Fgure 8) t a = r.v. representng the tme between I/O W p(p ) = stream ntaton catch-up wndow for polcy p, relatve to poston p Wp m (p ) = maxmum mergng wndow for polcy p, relatve to poston p BW p = mean total I/O demand (under polcy p) (bts/sec) Note that, below we do not gve equatons for ether W p(p ) or W m p (p ), where p could be the odd-even (oe), smple (sm), or greedy (g) polcy. These equaton can be found n Secton 4. Note also, that the above mentoned equatons, for W p(p ) and W m p (p ), already allow for the lmted mergng case,.e., the case where there s a lmt on the maxmum allowed mergng tme. Frst let us derve the densty functon of t a, whch s the nterarrval tme between two streams arrvng to the versons of an object, each correspondng to a derent dsplay rate. For nstance, n the smple mergng polcy, we only need the slow and the fast versons whle n the maxmum mergng wndow (W m sm (0)) and only the normal verson outsde of the maxmum mergng wndow. storage server. Snce the request arrval rate s Posson wth rate, t e = 1. Therefore, the densty functon of ta s: f t a(x) = e?(x?t) for x T (18) request arrval (starts a new batchng nterval) T t e stream arrval t a T stream arrval Fgure 8: Arrval of I/O streams after a delay. tme Snce the normal duraton of a move object s p M =, N, the expected number of I/O streams that the storage server has to support s: N = pm R 1 T 1 xfta (x)dx = pm =Sn 1= T (19) 5.1 Analyss of baselne polcy We begn wth the analyss of the baselne polcy, whch s very smple, snce there are no merges and each stream carres a xed cost of C n; the expected bandwdth demand s: BW b = NC n = pm =Sn Cn (20) 1= T The expected bandwdth demand wthout batchng can be obtaned by settng T = Analyss of odd-even polcy The behavor of the odd-even polcy s such that pars of consecutve I/O streams are statstcally dentcal. We can therefore analyze the mean I/O demand for one such par, and then compute the average I/O bandwdth by multplyng half the rate of ntensty of I/O streams by the average demand per par. Under the odd-even polcy, merges are possble under certan ranges of nterarrval tmes and batchng delays. Consder two consecutve streams s1 and s2 whch arrve to the system x tme unts apart (assume that s2 s the laggng stream). Assume for the moment that t s possble for these streams to merge, and let t m be the tme t would take s1 and s2 to merge, computed from the tme of s2's arrval. Let t f be the tme from the merge pont of these two streams untl the end of the object's dsplay; then: t m = t f = x? Smn (21) pm? (tm x)smn (22) Note that mergng s possble only f two streams arrve wthn the catch-up wndow W oe(0). Therefore, the combned I/O demand for streams s1 and s2, gven that they arrved x tme unts apart and that they can merge (.e., that x Woe(0) ) s: BW m oe = (t m x)c mn t mc max t fc n (23)

9 The three costs correspond to the bandwdth demands of: a) the leadng stream, s1, rst movng at dsplay speed, b) the tralng stream, s2, rst movng at dsplay speed, and c) the remanng I/O demand, after mergng, and contnung dsplay at the speed of. Smlarly, f x > Woe(0), then the I/O demand of the par of streams s: Woe(0) = 2 C mn BW nm oe pm? Woe(0) C n (24) The expresson corresponds to each of the streams at rst havng a dsplay speed of and after movng beyond the catch-up wndow, resetng the dsplay speed to. At ths pont, we can compute BW oe,.e., the total mean bandwdth demand n the system: R Woe(0) T (BWoe m N BW oe = 2 fta (x)) dx p M R 1Woe(0) (BWoe nm N 2 S fta (x)) dx mn p M (25) 5.3 Analyss of smple mergng polcy The analyss of the smple mergng polcy s smlar to that of the odd-even polcy, except that nstead of lookng at pars of streams, we consder \mergng groups" of streams,.e., groups of streams that eventually all merge together (see Secton 4). Smlarly to the odd-even polcy, we note that all \mergng groups" are statstcally dentcal, and hence we can analyze the mean I/O demand for one such group and compute the average I/O demand by multplyng the rate of ntensty of such groups by the I/O demand for each group. Under the smple mergng polcy, mergng s possble f upon ntaton of a stream, there exsts another stream wthn the catch-up wndow, W sm(0), whch s movng at speed. Let be the number of streams, wthn the wndow W sm(0), that can (eventually) be merged; we call ths set of streams a \mergng group". We approxmate by: = max b Wsm(0)=Smn 1c; 2 T 1= (26) The rst component corresponds to the number of streams that can fall wthn wndow W sm(0); by settng 2, we consder the (mergng) eect when at least 2 streams are avalable for mergng. Assume that all streams n a mergng group are separated by tme x and that there are mergng streams wthn the catch-up wndow W sm(0). The second stream needs t m (or x Smax? ) tme unts to catch up to the leadng stream (.e., the rst stream n the group), the thrd stream needs 2t m tme unts to catch up, etc. The leadng stream wll keep the dsplay speed at untl t reaches poston W m sm(0), then the dsplay speed wll be reset to. Therefore, the amount of tme durng whch the leadng stream has the dsplay speed of s: t f = pm? W m sm(0) (27) The I/O demand for the mergng group, gven that they are separated by tme x and that mergng s possble, can be expressed as: BW m sm = W m sm(0) C mn C()t mc max t fc n (28) where C() = (? 1)=2. The cost terms correspond to the cost of the leadng stream movng at and all other streams, orgnally wthn the catch-up wndow W sm(0), movng at speed, tryng to catch-up. The last cost term represents the remanng tme after the last merge, when the leadng stream moves at speed. If, on the other hand, mergng s not possble for a gven nterarrval tme x, then the I/O demand for the mergng group s: W m sm (0) BW nm sm = C mn pm? W sm(0) m C n (29) The expected I/O demand for the smple mergng polcy s: R Wsm(0) T (BWsm m N BW sm = fta (x)) dx p M R 1Wsm(0) (BW nm sm N fta (x)) dx p M (30) 5.4 Analyss of the greedy polcy The performance analyss of the greedy polcy s more complex. Let us rst refer to Fgure 9 and consder the mergng pattern. Ths gure depcts a system wth eght streams. All of them start out x tme unts apart, and eventually, all eght streams can be merged nto one. Note that for the rst level merge (refer to Fgure 9, the system reduces the number of streams by half but all remanng streams (e.g., s1; s3; s5; s7) are 2x tme unts apart. After the second level merge, only two streams reman, s1 and s5, and they are 4x tme unts apart. Wth ths observaton, let l be the hghest level of merges under the greedy polcy. The expresson for l s: where and l = max fk : g(k) > 0g (31) g(k) = p M? 2 (k?1) h? Smn (32) Z Wg(0) = xf t a(x) dx T h = T 1? "( W g(0))e (? Wg(0)? T # ) (33) Gven that the streams can go through l levels of merges, the leadng stream, after the last mergng pont, wll have t f tme unts of dsplay left, at a speed of, where t f s: t f = hp M? 1 lx? 2 j?1 j=2?smn h?smn # h 1 (34)

10 level 1 merge level 3 s s 1 level 2 merge 5 s merge 7 s 1 s 5 s 8 s 7 s 6 s 5 s 4 s 3 s 2 x 2x 4x s 3 s 1 s 1 Fgure 9: Mergng pattern for streams under greedy polcy. where the rst term represents the remanng frames of the object, after the last mergng event, dsplayed at the speed of. Gven that the nterarrval tme between streams, partcpatng n a l level merge, s x, and that there are l 2 levels of merges, the I/O demand s: where BWg m (tm x)c mn t mc max = lx j=2 h(j) = 2 (j?1) h N p M = 2 h(j) Sn h N tfcn h N p M 2 j p M = 2 l (35) h C n (C mn C max) (36)?Smn The rst term n Eq. (35) represents the bandwdth demand for the rst level merge whle parng up N 2 streams. The second term represents the bandwdth demand for the second level, etc., untl the l th level merge whle parng up N 2 pars. (Note that for level two and up, the leadng stream l wll rst move at because t wll nsh mergng earler than the next pars of tralng streams; when the tralng streams nally nsh ther merge, ts dsplay speed wll be reset, from to, whle the tralng stream (resultng from the merge) wll attempt to catch-up at the speed of.) The thrd term represents the bandwdth demand for the leadng stream, movng at the dsplay speed of, all the way untl the end of the object's dsplay. If merges are not possble, gven x, then the I/O demand wll be: " W g(0) BWg nm S = mn C mn p M?Wg(0) # C Sn n N (37) p M = uncondtonng on the nterarrval tme x, we have: BW g = Z Wg(0) T Z 1 (BW m g f t a(x)) dx (BW nm g f t a(x)) dx (38) Wg(0) Fnally, we constran the bandwdth demand of the odd-even polcy to be the upper bound for the bandwdth demand of the greedy polcy,.e., BW g = mn(bw g; BW oe) (39) 5.5 Valdaton of Analytc Results In concluson of ths secton, we valdate our our analytc results (see Secton 5) by comparng them to results obtaned from smulaton. These comparsons, of all three polces n conjuncton wth batchng by tmeout (see Secton 3) are depcted n Fgures 10-12, where \delay" refers to the batchng nterval (n mnutes) and each curve represents the percentage mprovement n I/O demand, as compared to the baselne polcy. They ndcate that the largest dvergence from the smulaton occurs when the arrval rate s low; the analytc result match the smulaton closely when the arrval rate s moderate to hgh. Ths s sucent for our purposes snce we are nterested n applyng our technques to vdeo objects wth relatvely hgh access rates,.e., popular objects. Improvement n BW (%) Improvement n BW (%) Comparson to Smulaton (odd-even) delay=8 (sm) delay=8 (analytc) delay=0 (sm) delay=0 (analytc) delay=5 (sm) delay=5 (analytc) Inter Arr Tme (mn) Fgure 10: Odd-even polcy. Comparson to Smulaton (smple) delay=8 (sm) delay=8 (analytc) delay=0 (sm) delay=0 (analytc) delay=5 (sm) delay=5 (analytc) Inter Arr Tme (mn) Fgure 11: Smple polcy. 6 Dscusson of Results In ths secton we present results of studes of adaptve pggybackng polces n conjuncton wth batchng polces. To

11 Comparson to Smulaton (greedy) 40 Improvement n BW (%) delay=0 (sm) delay=0 (analytc) delay=5 (sm) delay=5 (analytc) delay=8 (sm) delay=8 (analytc) Improvement n BW (%) mean nterarrval tme = 4 mn odd_even smple greedy Inter Arr Tme (mn) Delay (mn) Fgure 13: Varyng Delay. Fgure 12: Greedy polcy. 80 avod degradaton n dsplay qualty, we assume that the adjusted rates, and, are wthn 5% of the normal dsplay rate, (see Secton 2). In the remander of ths dscusson, we use the the followng values for the parameters presented n Secton 4: = 28:5 frames/sec = 30:0 frames/sec = 31:5 frames/sec C mn = 1:425 Mbts/sec C n = 1:5 Mbts/sec C max = 1:575 Mbts/sec Batchng by tmeout (see Secton 3) s used as the batchng polcy n all results presented n ths secton. The delay tme s vared between 0 and 10 mnutes, and the mean nterarrval tme (between consecutve requests for the same move) s vared between 0:5 and 10 mnutes. In the followng dscusson, we consder the total average I/O bandwdth demand on the storage server as the measure of nterest. More speccally, n each graph, we present the percentage mprovement, of varous polces, as compared to the baselne polcy. For ease of exposton, we ntally assume no restrctons on the maxmum allowed mergng tme (see Secton 4). At the end of ths secton, we consder the eect of restrctng merges to occur wthn a speced tme nterval. We rst consder the aects of batchng,.e., the decrease n I/O demand on the storage server due to batchng and the correspondng ncrease n the average latency for startng the servce of a request. Ths comparson s llustrated n Fgure 13, where the nterarrval tme s kept at 4 mnutes and the batchng delay s vared between 0 and 10 mnutes. Ths graph ndcates that, as the batchng delay ncreases, the decrease n I/O demand quckly shows dmnshng returns whle the average latency, whch grows almost lnearly wth the batchng delay (see Equaton (1) n Secton 3), contnues to grow. Next, we compare the adaptve pggybackng polces, but wthout batchng; the results of ths comparson are depcted n Fgure 14 (as a percentage mprovement over the baselne polcy), where the nterarrval tme s vared between 0:5 and 10 mnutes. Ths graph ndcates that the Improvement n BW (%) wthout batchng odd_even smple greedy Inter Arr Tme (mn) Fgure 14: Varyng Arrval Rate (no batchng). odd-even polcy results n a sgncant reducton n I/O demand; recall, that the odd-even polcy allows each I/O stream to partcpate n (at most) a sngle merge, and hence t can result n (at most) a 50% decrease n I/O demand. For the cases presented n Fgure 14, the reducton n I/O demand, as compared to the baselne polcy, ranges from 47:92%, correspondng to a farly small nterarrval tme of 0:5 mnutes, and 20:92%, correspondng to a farly large nterarrval tme of 10 mnutes. Further reducton can be acheved by allowng each I/O stream to partcpate n multple merges, for nstance, by usng the greedy polcy. The results for the greedy polcy (wthout batchng) are also llustrated n Fgure 14, where we acheve a further reducton n I/O demand; agan, as compared to the baselne polcy, the results for the greedy polcy range from 81:0%, for the farly small nterarrval tme of 0:5 mnutes, to 20:92%, for the farly large nterarrval tme of 10 mnutes. The results are qualtatvely smlar, when batchng s used n conjuncton wth adaptve pggybackng 15 ; however, due to lack of space we do not llustrate them here (see [8]). 15 Clearly, as the batchng nterval ncreases, the range of workloads over whch these polces exhbt sgncantly derent behavor decreases.