Inegraed Scheduling of Mulimedia and Hard Real-Time Tasks Hiroyuki Kaneko, John A. Sankovic, Subhabraa Sen and Krihi Ramamriham Compuer Science Deparmen Universiy of Massachuses LGRC, Box 346 Amhers MA 3-46 UMass Compuer Science Technical Repor 96-45 Augus 996 Absrac An inegraed plaform which is capable of meeing he requiremens of boh radiional real-ime conrol processing and mulimedia processing has enormous poenial for accommodaing various kinds of new applicaions. However, excep for he simples of siuaions, few, if any, research or commercial sysems successfully provide archiecural and OS mechanisms which can efficienly suppor boh hard real-ime compuaion and mulimedia sof real-ime compuaion. In his paper, we propose a mulimedia server execuing on muliprocessor real-ime operaing sysems o provide differen classes of guaranee o suppor boh ypes of processing. The mulimedia server suppors muliple periodic mulimedia sreams wih a capabiliy for graceful QoS degradaion during sysem overload. In his paper we (i) discuss realisic sysem implemenaion issues on he SGI IRIX/REACT/PRO operaing sysem, (ii) develop several mulimedia server scheduling algorihms, and (iii) presen a performance evaluaion. We chose he SGI sysem as an implemenaion plaform because i is being used more and more for mulimedia applicaions. Our performance evaluaion demonsraes ha a mulimedia server algorihm based on a flexible, proporional allocaion scheme provides he bes performance and ha simple ieraive scheduling is adequae for handling graceful degradaion of he mulimedia sreams. We consider issues such as server size and period as well as he impac of conex swich overhead on he performance. We also show ha for applicaions which require inegraed resource sharing, neiher he frame scheduler nor he deadline scheduler supplied in he IRIX/REACT/PRO OS This work was suppored by he Naional Science Foundaion Gran No. IRI-92892 and CDA-952639, and Misubishi Elecric Corporaion. are suiable. We propose an implemenaion soluion ha is appropriae.. Inroducion Many hard real-ime applicaions such as auomaed manufacuring and aack helicopers are being designed o ake advanage of audio and video informaion. This informaion has real-ime requiremens such as delay and jier olerance, requires suiable real-ime operaing sysem suppor, and is less criical han hard real-ime conrol informaion. However, suppor for processing his informaion mus co-exis wih he hard real-ime conrol informaion. For example, in aack helicopers such as he Comanche, conrol asks have o be execued wihin heir deadlines oherwise he helicoper will no fly. Audio and video sensors can provide monioring and sophisicaed conrol of he helicoper. To do his requires flexible and dynamic scheduling ha includes various ypes of ineracion beween he hard and sof real-ime conrol asks. Accommodaing mulimedia and radiional real-ime applicaions which have ineracion requiremens is a challenging research issue. However, lile aenion has been paid o he coexisence of hese applicaions. For example, he Mercuri sysem [?] is one of he few research projecs argeing his objecive, where daa from remoe video cameras are ransferred hrough an ATM nework and displayed in X windows, bu hey fail o provide any guaranees and end up wih providing bes effor services. This paper presens a mechanism o suppor he coexisence of mulimedia applicaions and radiional hard
real-ime applicaions ha inerac via shared use of CPUs, using he SGI Challenge muliprocessor and is IRIX/REACT/PRO OS. I develops various real-ime scheduling algorihms o provide he necessary scheduling suppor, and presens a performance evaluaion ha demonsraes he value of he soluions. We chose he SGI sysem as an implemenaion plaform because i is being used more and more for mulimedia applicaions. The res of his paper is organized as follows. Secion 2 inroduces several applicaions which can benefi from direc inegraion of hard real-ime conrol and mulimedia. Secion 3 presens he inegraed scheduling algorihms and a soluion ha can be used on he IRIX/REACT/PRO OS. In he simples of applicaions, a soluion can be based on complee pariioning of he wo classes of work. In his case, he frame scheduler or deadline scheduler of he IRIX/REACT/PRO OS can be used. For more complicaed applicaions, inegraed soluions are necessary, and we show ha he sandard IRIX/REACT/PRO schedulers canno be used. The QoS degradaion soluion is discussed in Secion 4. In Secion 5, simulaion resuls are presened. These show ha a mulimedia server based on a flexible, proporional allocaion scheme is highly effecive and ha a simple ieraive policy is adequae for handling QoS degradaion in overload. Secion 6 summarizes he work. 2. Applicaions Wih echnology like high performance CPUs, memory, disks and high speed neworks becoming less expensive and more easily available, a number of mulimedia applicaions have emerged boh in he commercial world and in research. A he same ime, radiional real-ime compuing is sill one of he major applicaions being used in various fields. In order o moivae he need for a plaform which is capable of supporing hese wo ypes of compuaions a he same ime, consider he following applicaions. Firs, even he coexisence of a simple video sream display and real-ime conrol processes requires new soluions. For example, suppose ha in a power plan or indusrial manufacuring plan, plan operaors (i) monior siuaions in differen locaions of he plan via cameras and (ii) conrol acuaors based on his monioring. Currenly hese analog video monioring sysems and digiized conrolling sysems are implemened on compleely separae plaforms. Replacing hese redundan sysems wih an inegraed digiized sysem can reduce he cos since he reducion in he number of cables, display equipmen, ec. is significan. In addiion o he reducion in cos, he inegraed digiized sysem can provide more funcionaliy. For example, processing of he audio and video by on-line algorihms may hen direcly conrol various acuaors for more effecive and faser response o problems. Also several video sreams can be shown on a single screen, informaion for hem can be fused, and auomaic conrol of acions migh be riggered, allowing faser and more accurae response. Many companies, including Honeywell and Misubishi, are pursuing applicaions wih similar characerisics. Second, many examples can be found in miliary applicaions such as conrolling he fly-by-wire Comanche helicoper hrough rees and elephone wires and looking for enemy soldiers or vehicles based on processing video and audio daa. Upon deecion of various siuaions from he video and audio processing, direc conrol of he helicoper may occur. The workload presened by his applicaion is highly dynamic and subjec o boh hard and mulimedia real-ime consrains. Third, compuer-paricipaive mulimedia applicaions are anoher emerging rend in mulimedia research [?]. As opposed o compuer-mediaed mulimedia applicaions such as online encyclopedias and video-conferencing sysems, in which he compuer acs as a mediaor beween he applicaion auhor and user or beween wo users, compuer paricipaive mulimedia applicaions perform analysis on heir audio and video daa inpu, and ake acions based on he analysis. For example, a sysem in which a program waches elevision news shows and mainains an online daabase of sories organized by subjec is inroduced in [?]. In his ype of applicaion, inpu daa have o be manipulaed or filered by sofware raher han hardware because of he flexibiliy required in he design. Similar applicaions can be seen in [?] and [?]. I is possible o make use of hese echniques for radiional real-ime sysems. For example, we may wan o know if here is any inruder in an isolaed area by filering he daa from he remoe monioring camera wih a moion deecion filer. The deecion can be direcly conneced o he alarm sysem or conrolling funcions such as shuing he valves or closing he gaes. We assume ha single processor sysems will no be used for hese applicaions since mulimedia processing is someimes very compuaion-inensive (e.g., he Comanche helicoper uses a muliprocessor as he main processing engine). In some of he ongoing muliprocessor-based research approaches, some processors are dedicaed o mulimedia processing and ohers o radiional real-ime processing, e.g., [?]. Alhough his approach can provide good isolaion of one ype of processing from anoher, i has several disadvanages: I canno achieve high uilizaion of sysem resources in a dynamic environmen. I is no effecive o dedicae hree processors for mulimedia processing when here is only one mulimedia 2
session and he res of he processors are overloaded wih real-ime processing. Allowing boh ypes of asks o exis in he same processor makes he sysem more adapable. This is he main ype of ineracion among hard real-ime and mulimedia asks ha is explicily addressed in his paper. Correcness may be jeopardized when he various ypes of processing inerac over shared daa resources. If he wo classes of work inerac over shared resources, reaing hem independenly may cause asks o miss heir deadlines due o possible blocking over hese shared resources. The soluions presened in his paper solve he blocking problem among hard real-ime asks hemselves, bu assume ha here is no read-wrie shared resources beween he hard real-ime and mulimedia asks. Our approach is herefore, o accommodae boh mulimedia and radiional real-ime processes in a muliprocessor sysem and allow boh ypes of processes o reside in any processor. Our soluion is described in he conex of he SGI Challenge muliprocessor and is OS. 3. Mulimedia Server 3.. Background The mulimedia server is a periodic ask ha is dynamically creaed and scheduled along wih hard real-ime asks. We use a planning-based scheduler, as exemplified by he Spring scheduling algorihm [?], o perform his level of scheduling. The server hen execues he mulimedia asks hemselves. A planning-based scheduler dynamically generaes schedules or plans in which every ask included in he schedule is guaraneed is required resources (including a processor) for is wors case execuion ime. When a new se of asks arrives a he sysem, i aemps o assign execuion windows for he new asks and every ask in is curren schedule such ha every ask complees by is deadline and here are no resource conflics beween any asks scheduled o execue a he same ime. If a feasible schedule canno be found, he new se of asks is rejeced and he previous schedule remains inac. This planning allows admission conrol and resuls in a reservaion-based sysem. The key aspec of his scheduler is is abiliy o schedule no only he CPU bu also he oher required resources in an inegraed fashion. On he basis of his planning-based scheduling algorihm, we inegrae mulimedia and hard real-ime processes using a mulimedia server. The server is given a fracion of CPU ime and is responsible for conrolling he execuion of mulimedia asks. Task execuions of muliple mulimedia sreams are muliplexed ino one mulimedia server insance. Hard real-ime asks are execued in he res of he CPU ime. Of course, i is possible ha we regard each mulimedia ask insance as a hard real-ime ask and schedule i wihou having he mulimedia server. However, he cos involved in individually scheduling hese ask insances using he planning-based scheduler would be oo high. Is capabiliy o provide more precise guaranees per ask insance is essenial for he hard real-ime conrol asks, bu his level of deerminism is no needed for mulimedia sessions which can do wih more saisical ypes of guaranees. 3.2. Mulimedia Task Allocaion Policies In his paper, we invesigae boh saic and flexible allocaion schemes as well as proporional and individual allocaion schemes. This gives rise o four differen combinaions. Saic proporional allocaion Saic individual allocaion Flexible proporional allocaion Flexible individual allocaion This secion discusses hese differen schemes and Secion?? describes how hese various combinaions are inegraed wih he planning-based scheduler. Saic versus Flexible Allocaion. Obviously, here can be many differen policies for allocaing a fracion of CPU ime o he mulimedia server. One clear disincion is beween a saic allocaion and a flexible allocaion. Wih saic allocaion, he sar ime and duraion of each mulimedia server insance are fixed beforehand. Then he on-line scheduler ries o guaranee he hard real-ime asks by scheduling hem ino he CPU ime no used by he mulimedia server. Therefore, scheduling of mulimedia sreams is separaed from scheduling of hard real-ime asks and is no direcly relaed o he planning-based scheduling algorihm. The saic allocaion can be considered a baseline and is no expeced o perform very well. On he oher hand, wih he flexible allocaion, each mulimedia server insance is reaed as one real-ime ask and dynamically scheduled wih he planning-based scheduling algorihm. The sar ime of each mulimedia server insance can be moved beween is release ime and is deadline minus server compuaion ime. The release ime and deadline are calculaed based on he period of he mulimedia server as described below. The scheduling overhead of he flexible approach is higher han 3
mulimedia sream mulimedia sream 2 mulimedia sream 3 mulimedia server P P P X 2 P X 3 Figure. Proporional allocaion of mulimedia sreams. nework Flexibiliy in ask execuion is needed especially when several mulimedia sreams are muliplexed. For example, Figure only illusraes how he compuaion ime of he server insance is decided, no he order in which asks are execued wihin he server. In pracice, due o he high variabiliy in mulimedia sream processing, i is virually impossible o execue he asks wihin he server in he way he figure shows. The only hing ha he sysem has o guaranee is ha every mulimedia sream ges is requesed fracion of ime in he server. Alhough his lack of deerminbuffer shared memory app. process applicaion processor frame buffer (secondary) frame buffer (primary) videoboard video display sysem bus Figure 2. An example applicaion sysem. ha of he saic approach because he planning-based scheduler has o schedule mulimedia server insances in addiion o hard real-ime asks. However, schedulabiliy of hard real-ime asks is much lower wih he saic allocaion han wih he flexible allocaion since he former is much more resricive in iming. Proporional versus Individual Allocaion. For boh saic and flexible allocaion schemes, here are wo ways o assign each mulimedia ask insance o he mulimedia server insance. One is called proporional allocaion where each ask insance is spli proporionally ino he mulimedia server. Suppose here are n differen mulimedia sreams in he sysem. Le P S be he period of he mulimedia server, P i be he period of he i-h mulimedia sream, L S be he ime duraion of each mulimedia server insance and L i be he esimaed execuion ime of he ask insance in he i-h mulimedia sream. Then, since each ask insance is divided ino P Pi S server insances, he compuaion ime of he mulimedia server insance L S is given as L S = nx i= (L i P S P i ): Figure illusraes his allocaion scheme. As he mulimedia sream has he shores period P, he server has he same period as sream, namely P. In his example, he lengh of each server insance is he sum of he execuion imes of he ask of sream, half of sream 2 and one hird of sream 3. ism is inolerable for hard real-ime asks, for mulimedia asks, some amoun of jier caused by he execuion delay can be oleraed. For example, in he archiecure considered here, a ypical ype of processing of he mulimedia ask can involve aking frame daa ou of he buffer, processing i and puing i ino he secondary frame buffer on he videoboard (Figure 2). A he end of he processing, he ask issues he draw command o he videoboard, hen he videoboard ransfers he daa on he secondary buffer wih some processing ino he primary buffer. The frame daa wrien in he primary buffer will be displayed on he screen by hardware. Here, as long as he display commands are issued a some requesed rae, he specific deadline of each issue does no necessarily have o be defined. A he same ime, he ransfer of frame daa o he videoboard can be sared jus afer he display command of he previous frame is issued. Therefore, he release ime of he asks do no have o be sricly enforced eiher. In fac, he execuion ime of a mulimedia ask depends largely on he amoun of daa i processes, hus i is someimes difficul o esimae a priori he wors case execuion ime of he ask. The amoun of execuion ime needed o play back a single frame varies a lo and even he average execuion ime needed over a group of picures shows considerable variaions as a resul of changes in scene or video conen [?]. The adapable scheduling inroduced by he proporional allocaion scheme is well suied for hese various applicaion requiremens. Anoher mulimedia ask assignmen approach is o assign each mulimedia ask insance individually o a server insance. We call his he individual allocaion scheme. Here again, he period of he server is he same as he minimum period of all mulimedia sreams muliplexed ino he server. For example, in Figure 3, here are hree mulimedia sreams and he sream wih he shores period is sream 2, hus he server has he same period as sream 2 and all he asks in sream 2 are allocaed o he server insances wih heir locaions unchanged. Then he asks in sream and sream 3 are allocaed o heir neares server insances. The server insance o which he ask is assigned has o be locaed beween he ask s release ime and deadline. If such 4
mulimedia sream 3.3. Scheduling Algorihm mulimedia sream 2 mulimedia sream 3 mulimedia server Figure 3. Individual allocaion of mulimedia sreams. mulimedia sream mulimedia sream 2 mulimedia server L # #2 #3 #4 deadline of # L deadline of #2 deadline of #3 Figure 4. Deadlines of he flexible individual allocaion. a server insance canno be found, a new server insance has o be creaed. The order in which asks are execued inside he server can be decided by using he earlies deadline firs algorihm. Each server insance has o keep sae informaion on which asks i is responsible for and in wha order i has o execue hem. As opposed o he proporional allocaion scheme, he individual allocaion mehod can provide deerminisic guaranee for each execuion of he mulimedia ask insance. Each ask insance is execued exacly in he allocaed ime when he saic allocaion approach is aken. Even if we ake he flexible allocaion scheme for he mulimedia server insances, we can execue each ask insance deerminisically wihin is deadline by choosing he deadline of each mulimedia server insance in he following way. Suppose we have wo mulimedia sreams, sream and sream 2 (Figure 4), and he compuaion ime of a ask insance in sream is L. A firs, we make a deadline of a server insance he same as he sar ime of is nex server insance. For example, in he figure, he deadline of he server insance # is he sar ime of he server insance #2. Then we muliplex he sream wih he server. The firs ask insance of sream is aached o he server insance #2 and he deadline of he server insance #2 is exended by L because as long as he order of execuion is mainained, he execuion of he ask insance of sream 2 wihin is deadline is guaraneed. In he previous secion, we discussed four differen mulimedia server assignmen policies. In general, any one of hem may be chosen based on he sysem requiremens and is performance for ha sysem. Regardless of which one is chosen, a runime, he scheduler akes he following seps. We have o consider separaely he cases when a mulimedia sream comes ino he sysem and when a hard real-ime ask eners. In he former case, if no mulimedia sream already exiss in he sysem, he scheduler creaes a new mulimedia server whose compuaion ime and period are he same as hose of he incoming sream. On he oher hand, if one or more mulimedia sreams already exis in he sysem, he scheduler merges he new sream ino he server using he chosen assignmen policy (proporional or individual). If he period of he incoming mulimedia sream is smaller han ha of he curren server, a new server is creaed wih period equal o ha of he new sream. Insances of he new server will replace hose of he old one a he earlies possible ime a which he changeover can occur wihou violaing he QoS guaranees of he exising mulimedia sreams. An upper bound on his changeover ime delay is he LCM of he periods of he exising mulimedia sessions. Afer seing up he mulimedia server for he incoming sream, he scheduler ries o schedule he hard real-ime asks ha reside in he sysem. If we ake he saic allocaion approach, we jus ry o pu he hard realime asks ino he unused CPU ime ouside he mulimedia server using he planning-based scheduling algorihm described before. If we ake he flexible allocaion approach, we regard each mulimedia server insance as one hard realime ask and schedule i along wih oher server insances and hard real-ime asks. If he scheduling is no successful, he incoming mulimedia sream is rejeced o ensure he execuions of already guaraneed mulimedia sreams and he hard real-ime asks. In boh cases, he scheduler aemps o schedule all server insances whose period sar imes are before he laes deadline of he exising hard real-ime asks. If he scheduling is no successful, he incoming mulimedia sream is rejeced o ensure he execuions of already guaraneed mulimedia sreams and he hard real-ime asks. In he case of he arrival of a hard real-ime ask, he procedure is slighly differen. If he deadline of he incoming ask is earlier han he laes deadline of he exising asks, he scheduler aemps o schedule he he curren ask se plus he new ask. Oherwise, he scheduler needs o creae more mulimedia server insances whose period sar imes are before he deadline of he incoming ask. Afer he creaion of hese server insances, he new ask se will be esed for scheduling. If he scheduling is no successful, he 5
new hard real-ime ask is rejeced. This scheduling procedure ensures ha he already admied mulimedia sreams or real-ime asks are always guaraneed o be execued no maer how many asks arrive laer. Of course, a differen approach is possible here. If hard real-ime asks have higher prioriy over mulimedia sreams, we can reduce he QoS guaranees provided o exising mulimedia sreams so ha a subsequen aemp a building a feasible schedule is more likely o succeed and he incoming hard real-ime ask is guaraneed. We will discuss his issue in Secion 4. Before acually running he scheduling algorihm, making a preliminary admission es wih he esimaed execuion ime may be helpful. Tha is, if he sum of he ask s execuion ime is greaer han he amoun of CPU ime ha he sysem can provide, here is no way ha he scheduler can creae a feasible schedule. Wih his es, he sysem can ake some acions much more quickly since he cos of his es is much less han ha of he acual scheduling es. In order o make his admission es, he scheduler has o calculae he percenage of CPU ime mulimedia asks use in a scheduling ime period l and he percenage of CPU ime hard real-ime asks use. Now le us call he raios mulimedia server raio and hard real-ime ask raio and denoe hem by Rs and Rr, respecively. In he case of he proporional scheme, since all he server insances have he same compuaion ime and he same period, Rs is equal o (server compuaion ime / server period). For example, if we have 2 ms of server compuaion ime and ms of server period, he mulimedia server raio Rs is 2% and ha means 2% of he CPU ime will be allocaed o he mulimedia asks. Rs of he individual allocaion scheme is sum of he compuaion imes of he server insances divided by he scheduling period which is he lengh of ime from he curren ime o he laes deadline of he hard real-ime asks. The hard real-ime ask raio Rr is also sum of he execuion imes of he hard real-ime asks divided by he scheduling period. In order for he schedule o be successful, Rs + Rr has o be a leas less han % (he number of processors). If Rs + Rr is greaer han % (he number of processors), he incoming reques is immediaely rejeced or a degradaion approach is aken, depending on he policy in effec a ha ime. 3.4. Implemening he scheduling algorihm on an SGI Challenge Muliprocessor The SGI Challenge muliprocessor sysem [?], Figure 5, is a shared memory, symmeric muliprocessor archiecure. This archiecure has four levels of memory hierarchy - wo levels of cache (on-chip cache and cache on he CPU board), main memory and disk. There is a : access speed difference beween successive levels of he memory hierarchy. CPU CPU CPU CPU j n SP Global Memory AP_SET AP AP j... SCSI Inerface... VME Inerface.2 GB/sec Figure 5. Archiecure of SGI/Challenge Muliprocessor. The processors and global main memory are conneced via a.2 Gigabyes per second processor bus. Deails of Scheduling Mechanisms buil ino SGI s OS. IRIX TM [?,?] is a commercial, UNIX based OS which has been opimized for muliprocessor performance. I offers many ineresing feaures which are useful for supporing real-ime applicaions. These include memory mapped I/O, asynchronous I/O, he opion o lock pages in memory o avoid unpredicable page faul delays, he faciliy o direc inerrups o or away from specific CPUs, and o isolae and resric subses of CPUs o execue only specific processes using specific scheduling disciplines ec. The IRIX/REACT/PRO faciliies which are capable of supporing real ime and mulimedia applicaions in cerain scenarios are he he Frame Scheduler and he Deadline Scheduler. The REACT/PRO Frame Scheduler isolaes a CPU and uses a cyclic execuive o schedule and dispach seleced processes on ha CPU. I supersedes normal IRIX scheduling for his CPU and direcs all oher processing, daemons, and inerrup handling overheads away from i. Given a se of real ime processes wih periods and wors case execuion imes, he user has o compue he major and minor frame raes for he scheduler, and queue he processes for service in one or more minor frames. The frame scheduler hen services he minor frames in order, once every major frame. In each minor frame, he processes queued for service in ha frame are served in queue order, possibly muliple imes, unil he minor frame ends. I is possible o use muliple synchronized frame schedulers for concurrenly execuing a se of real ime processes on a subse of CPUs. The frame scheduler is more suiable for saic scenarios characerized by a fixed se of asks whose requiremens do no change over ime. In more complex environmens characerized by dynamic even arrivals, he frame scheduler is no suiable since he minor and major frame values may have o be poenially recompued and allocaion of processes o minor frame queues re-deermined. To do his, he frame scheduler would have o be paused, is parameers modified and processes reassigned o minor frame queues, before he 6
scheduler can be resared. This emporary pause in he scheduler would cause unaccepable disrupion in service. The Deadline Scheduler [?] aemps o guaranee execuion raes o sessions. The admission conrol checks if he oal CPU-ime allocaion for all he processes over a predefined frame inerval is below a maximum limi and if so he requesing process is admied. The processes are arranged in he scheduling queue according o ime-o-deadline and are serviced in round-robin order. Alhough IRIX does implemen he basic prioriy inheriance proocol [?] o preven he unbounded prioriy inversion problem, blocking by lower prioriy asks can sill occur [?]. Unless he resources required by he real-ime applicaions are carefully isolaed, hey may also be delayed due o blocking over a resource held by a process in he ime-sharing class. However, he analysis for admission conrol does no accoun for he delay erms due o his blocking. Deadlocks can also occur and can resul in violaion of he guaraneed QoS. Also his scheduler is primarily suied o handling periodic asks. The only way aperiodic hard real ime asks can be accommodaed is by reaing hem as periodic for admission conrol (his makes he admission conrol very pessimisic) and explicily removing he ask from he scheduling queue a he end of is execuion. I is also no clear how he deadline scheduling can provide he guaraneed raes over muliple processors. Based on his discussion we can say ha neiher he Frame Scheduler nor he Deadline Scheduler buil ino IRIX/REACT/PRO suis our needs. In he following secion, we ouline how our planning based soluion can be implemened on op of IRIX in he SGI/Challenge archiecure, by using a differen mechanism. Deails of implemening a Planning-based Approach. A supervisor process, called MASTER, execuing a a very high prioriy on CP U, which is designaed he sysem processor (SP), will group processors ino a processor se called AP SET. The processors in his se, called applicaion processors (AP), will be acually execuing he hard real ime and mulimedia applicaion asks and for predicable performance, need o be spared from unpredicable inerrupdriven workloads. MASTER isolaes and resrics each AP in he se using he following seps: Specify ha he sysem processor will perform all he overhead processing relaed o he scheduling clock inerrups. Isolae he APs from sprayed inerrups. Assign I/O inerrups o eiher he SP or a separae I/O processor. Resric each AP from execuing processes ha are no explicily assigned o i. Isolae each AP from TLB misses. As long as an isolaed CPU execues only processes whose pages are locked ino memory, i will receive no broadcas/tlb inerrups from oher CPUs as acions by processes in oher CPUs canno change he address space mapping of any process on his CPU. Now he sysem is configured o provide inegraed suppor for mulimedia and hard real ime asks. The supervisor running on he SP, execues he server allocaion algorihm and he planning-based scheduler on dynamically arriving asks. Iniially he sysem is idle and hen some asks (mulimedia sessions and aperiodic hard real ime asks) arrive. If MASTER is successful in finding a feasible schedule for he incoming workload, he oucome is a dispach able wih one column for each AP - his is he dispach lis for ha AP. The lis consiss of a series of uples (i; SST i ; SF T i ), where i is he process idenifier, SST i and SF T i are he scheduled sar ime and scheduled finish ime, respecively. (SST i ; SF T i ) defines a scheduling inerval over which i is guaraneed o execue on he corresponding AP.. The maser now allocaes a dispach ask D j o each AP j using he runon() command. D j is given a prioriy in he real ime class and is resriced o run only on ha AP. In IRIX, he real ime class is a band of prioriies in he range 3-39. Processes allocaed o his range do no have heir prioriies degraded, and he sysem accords hem he highes imporance nex o kernel processes. 2. A his poin, he dispach ask is he only ready-o-run eligible ask on each AP and herefore he OS sars i. 3. The dispach ask D j does he following: (a) I goes o he dispach lis in main memory for AP j, finds he nex uple (i; SST i ; SF T i ). This indicaes ha process i has o be execued nex from ime SST i o SF T i. (b) If he scheduled sar ime SST i > T curren, he curren ime, i will sar a imer o expire a SST i and go o sleep on ha imer. The imer will be execuing on he sysem processor SP. When i imes ou, an inerrup is sen o AP j. (c) When he imer inerrup arrives, he ISR on he AP awakens he dispacher D j and reurns. The dispacher runs immediaely, being he only eligible runnable ask on ha processor. (d) D j now checks if he process i is already in he real ime queue of he AP. If so i mus have 7
execued a leas once before on his AP, and been suspended a he end of is allocaed ime. The dispacher hen uses he resume() sysem call o make he process ready, sars a imer o expire a SF T i and goes o sleep. (e) If he process i is being execued for he firs ime on processor AP j, he dispacher D j will i. allocae he process o he real ime prioriy class a a lower prioriy han D j, and resric he process o execue only on processor AP j ; and ii. hen sar a imer o expire a SF T i and go o sleep. Noe ha since he dispacher is execuing a a higher nondegrading real-ime prioriy han he process i, i will no be preemped by he laer, before i volunarily suspends iself. (f) Now i is he only eligible ready-o-run process on AP j and so i is dispached nex. I now execues unil i eiher finishes, or he ime advances o SF T i when a imer inerrup occurs. (g) When he imer goes off, he ISR suspends process i if i has no ye finished, wakes up he dispacher and reurns. D j now feches he nex uple from he dispach lis and he whole proocol repeas iself. The dispach able is a shared daa srucure in global main memory, which is accessed by he differen dispachers from each AP as well as by he maser scheduler-planner. Differen dispachers need o access differen columns in he able and so do no inerfere wih each oher. Also, he maser and dispacher on any AP are always working on differen pars of he dispach able. Whenever new asks arrive a ime T curr, he maser compues, an upper bound on he ime available for i o compue and reurn a feasible schedule if such a schedule exiss. is chosen large enough so ha here is a high probabiliy of finding a feasible soluion wihin his ime, bu a he same ime, he response of he scheduler o dynamic arrivals is no oo slow. MASTER hen draws a cuoff line in he dispach able a T curr + and aemps o make modificaions o he par of he curren schedule which are beyond his cuoff line. This avoids race condiions beween he maser and dispacher asks on accesses o he shared dispach lis. The implemenaion of he dispach able can be similar o he one used in he Spring real ime kernel [?]. The scheduling queues in IRIX are implemened in a disribued fashion o permi a high level of concurren access [?]. There are local per-processor squeues on which only processes which are resriced o ha processor and processes which have affiniy for ha processor are queued. Oher processes are mainained on he cenral global queue. In our case, he APs are explicily resriced o execuing only he dispacher and he hard real ime asks and mulimedia servers as allocaed o hem by he maser process. Also each hard real ime ask or mulimedia server is resriced o be execued only on ha AP o which i is queued. So he OS, when i needs o search for he nex ask o execue on a paricular AP has o look only in is local squeue. All his ogeher ensures ha he performance is predicable and ask execuions are as laid ou by he scheduler-planner. Noe ha o preven he unpredicable delays and nondeerminism caused by page fauls, all he pages of he supervisor process, he hard real-ime asks and he mulimedia sessions, as well as shared pages (for example, he global dispach able) should be locked ino main memory. 4. Degradaion of QoS In our approach, he qualiy of service (QoS) requiremens of he mulimedia asks are mapped ino he compuaion ime and period of he mulimedia server. As saed in he previous secion, one way of alleviaing sysem overload is o degrade he QoS of he mulimedia sessions assuming ha hard real-ime asks have higher prioriies over mulimedia sessions. There are a couple of ways o achieve his degradaion of mulimedia QoS. For example, we can reduce he compuaion ime of he mulimedia server, increase he period of he server or even drop some of he server insances. However, deciding how o degrade he QoS of he mulimedia sessions so ha he scheduling of he hard real-ime asks will likely succeed and sill keep he degree of degradaion as low as possible is no very easy since he scheduling of he hard real-ime asks iself is a NP-hard problem. Moreover, he cos of he scheduling es is fairly high because he planning-based scheduler akes ino accoun all he resources of every ask. Therefore, our goal here is o find he bes server adjusmen plan, ha is, he plan which no only gives a feasible schedule for all he asks, bu also produces a schedule wih he highes value, i.e., gives he maximum amoun of CPU ime o he mulimedia server, wih a minimal number of scheduling ess. Here we presen a mulilevel scheduling approach as a soluion for he above problem. If he firs scheduling aemp fails, he scheduler passes he informaion on he mulimedia server and hard real-ime asks requiremens o he upper level algorihm. This upper level algorihm is referred o as a server planner in he following. The firs sep ha he server planner akes is o lower he server raio Rs as much as possible so ha i saisfies Rs + Rr + margin % (he number of processors). I hen ieraes as shown in Figure 6 o converge on a suc- 8
new mulimedia sreams or real ime asks arrive calculae Rs of he mulimedia sreams ime and period and how o quanify he resuling applicaion QoS is sill an open issue. scheduling es 5. Simulaion schedule succeeded? yes reurn 5.. Overview no upper_bound = Rs lower_bound = Rs * k(calculaed based on he sysem load) make server plans based on he new Rs choose he bes server plan using heurisics scheduling es schedule succeeded? yes lower_bound = Rs eners he server planner Rs = (lower_bound + upper_bound)/2 no upper_bound = Rs Rs = (Rs + upper_bound) / 2 Rs = (lower_bound + Rs) / 2 Figure 6. The ieraive server rae adjusmen algorihm. cessful server raio. Each ime ha a server raio is chosen, he server planner makes several server arrangemen plans. A server arrangemen plan is a choice of a server compuaion ime and server period such ha he overall server raio is me. For example, wo server arrangemens migh be a mulimedia server wih compuaion ime 2 and period 2, and compuaion ime and period. The server planner hen chooses he bes server arrangemen using a heurisic ha maximizes he laxiy for hard real-ime asks and invokes he base planning-based scheduler. The laer ries o schedule all he asks again wih he new mulimedia server arrangemen. If i is no successful, he server planner chooses he nex server arrangemen plan wih a lower Rs, and if successful, he planner chooses i wih a higher Rs. This ieraive process coninues unil he ieraion coun reaches a pre-defined number, i.e., he scheduler spends is allowed scheduling ime, or he rae of change in Rs is less han some pre-defined amoun. This scheduling process is summarized in he diagram in Figure 6. I is imporan o noe ha he mechanism presened here degrades mulimedia QoS in erms of he server compuaion The simulaions are divided ino roughly hree pars. Firs, he four differen sraegies for he mulimedia server scheduling obained by combining wo ypes of server allocaion policies and wo ypes of approaches for allocaing individual mulimedia sreams o he server insances are compared o find ou which combinaion provides he bes performance. Second, differen deadline and execuion ime disribuions of hard real-ime asks are inpu o he scheduler o furher evaluae he performance characerisics of he algorihms. Third, he effeciveness of he mulilevel scheduler for QoS degradaion of mulimedia sessions is examined. 5.2. Task Generaion A ask se generaor generaes a hard real-ime ask se and mulimedia sream se for each simulaion run. The real-ime ask se generaed by his generaor is, by iself, a feasible se. Tha is, in he absence of he mulimedia sreams, an opimal scheduler can find a schedule for he ask se. The following parameers are used o generae he hard real-ime ask ses:. Probabiliy ha a ask uses a resource, Use P. 2. Probabiliy ha a ask uses a resource in shared mode, Share P. 3. The minimum processing ime of asks, Min C. 4. The maximum processing ime of asks, Max C. 5. The minimum deadline of asks, Min D. 6. The maximum deadline of asks, Max D. 7. The schedule lengh, L. The schedule creaed by his ask se generaor is in he form of a marix M which has r columns and L rows. Each column represens a resource and each row represens a ime uni. In order o illusrae he process of ask se generaion, we assume ha here are n processors and m oher resources, i.e., he oal number of resources is n + m. Resource iems :::n represen n processors. The ask se generaor sars wih an empy marix. I hen generaes a 9
ask by selecing one of hese n processors wih he earlies available ime and hen requess he m resources according o he probabiliies specified in he generaion parameers. The generaed ask s processing ime is randomly chosen using a uniform disribuion beween he minimum processing ime and he maximum processing ime. The ask se generaor hen marks on he marix ha he processor and resources required by he ask are reserved for a number of ime unis equal o he ask s compuaion ime saring from he aforemenioned earlies available ime of he processor. The ask se generaor generaes asks unil he remaining unused ime for each processor, up o L, is smaller han he minimum processing ime of a ask, which means ha no more asks can be generaed o use he processors. Then he larges finish ime of a generaed ask in he se becomes he ask se s shores compleion ime, SC. As a resul, we generae asks according o a very igh schedule wihou leaving any usable ime unis on he n processors beween and SC. However, here may be some empy ime unis in he m resources. The deadline of each ask was chosen beween (finish ime of he ask + minimum deadline Min D) and (finish ime of he ask + maximum deadline Max D). The oupu of his ask se generaor is a file wrien in he Spring Sysem Descripion Language (SDL) [?]. The file describes all he ask informaion such as iming and resource usage specificaions needed by he planning scheduler. I is compiled by he Spring compiler and fed ino he simulaor. The ask generaor also places mulimedia sream informaion ino his file. In hese experimens we used 5 mulimedia sreams whose characerisics are described in he nex subsecion. 5.3. Simulaion Mehod In he simulaion, he performance of various server assignmen policies are evaluaed according o how many of he N feasible ask ses are found schedulable. Here, we are ineresed in wheher or no all he real-ime asks in a ask se and mulimedia server insances can finish before heir deadlines. Therefore, he mos appropriae performance meric is he schedulabiliy of ask ses. This meric called he success raio SR is defined as oal number of ask ses found schedulable. N;he oal number of ask ses All he simulaion resuls shown in his secion are obained from he average of six simulaion runs. For each run, we generae 5 ask ses (i.e., N = 5). The maximum 95% confidence inerval of any daa poin was 3.3% of he success raio. The sysem esed consised of hree processors and 2 nonprocessor resources. Use P is.7 and Share P is.5. Alhough he primary purpose of his simulaion is o compare he differen server assignmen policies and examine he effecs of changing he parameers, we normalized he simulaion ime uni ino milliseconds and chose realisic values for he parameers so ha we could assess he feasibiliy of our approach o some exen. The schedule lengh L is 3 ms, and a ask s compuaion ime is randomly chosen beween Min C and Max C. Thus, for example, when Min C = and Max C = 3, each ask se has beween 4 and 5 asks. Min D is 6 and Max D is 9, hus a deadline of each ask is randomly chosen beween 6 ms and 9 ms. We pu five mulimedia sreams wih differen compuaion imes and periods ino one processor. We made one of he five sreams a baseline sream wih a rae of 3 frames/sec and made four oher sreams wih a 2%, 4%, 6% and 8% lower rae han he baseline, respecively. Tha is, he period of he baseline sream is 33.3 ms and ha of he second sream is 4. ms (33.3 ms.2). Similarly, he hird, fourh and fifh sreams have a period of 46.6 ms (33.3 ms.4), 53.3 ms (33.3 ms.6), and 59.9 ms (33.3 ms.8), respecively. These periods correspond o frame raes of 25, 2.4, 8.8, and 6.7 frames/sec. These frame raes were kep consan hroughou he simulaions and only heir compuaion imes were varied. Each of he five sreams consumes he same amoun of CPU ime on average, ha is, if he compuaion ime of a ask insance in he baseline sream is 5 ms, compuaion ime of a ask in oher sreams are 6 ms (5 ms.2), 7 ms (5 ms.4), 8 ms (5 ms.6), and 9 ms (5 ms.8). If hese asks are allocaed o he server proporionally, he compuaion ime of each server insance is 25 ms (5 ms + 6 33:3 ms ms 33:3:2 ms 33:3 ms + 7 ms 33:3:4 ms + 8 ms 33:3 ms 33:3:6 ms + 9 ms 33:3 ms 33:3:8 ms = 5 ms5). If hey are allocaed o he server individually, each server insance has a differen execuion duraion and possibly a differen period. 5.4. Simulaion Resuls Comparison of he Server Allocaion Policies. The simulaion resuls wih he differen mulimedia server assignmen policies and no degradaion policy are shown in Figure 7. The X axis represens compuaion ime of he baseline mulimedia sream as described in he previous secion. In all he simulaion resuls shown, he success raio keeps decreasing as he mulimedia compuaion ime increases. This is because he increased mulimedia compuaion ime leaves less CPU ime for hard real-ime asks, hus he ighness of he scheduling increases. The resuls show ha he flexible allocaion works much beer han he saic allocaion. For example, when he baseline mulimedia compuaion ime is.2 ms, he success raio of he wo saic approaches goes down o %, whereas he flexible approaches achieve 8% and %. The proporional allocaion also works beer han he individual allocaion. Especially when he mulimedia compuaion ime is relaively shor, for ex-
Success Raio (%) 8 6 4 2 2 3 flexible proporional flexible individual saic proporional saic individual 4 5 Baseline mulimedia compuaion ime (ms) Figure 7. The server ypes and he success raio (period = 33ms). ample 2 ms, he flexible proporional approach has 99% success raio, bu he flexible individual sraegy has only 75%. Alhough hese resuls are as expeced, he significan difference beween he saic allocaion and he flexible allocaion approaches is noeworhy. Moreover, he difference beween he flexible proporional allocaion and he flexible individual allocaion indicaes ha he price we have o pay o ensure ha every individual insance of any MM session always execues wihin is deadline is quie expensive. This is mainly because he deadlines of he server insances in he flexible individual allocaion are someimes much shorer han hose in he proporional one. From hese resuls, we can conclude ha he flexible proporional assignmen policy provides he highes performance among he combinaions esed in erms of he success raio. Effec of Changing Parameers. In he following simulaions, only he flexible allocaion schemes are examined. Figure 8 shows he effec of changing he deadlines of hard real-ime asks on he success raio. The plain lines are he success raio when deadlines are chosen beween 6 ms o 9 ms, and he doed lines are hose when deadlines are beween 3 ms and 6 ms. Here, he shape of he curves in he differen deadline ranges looks almos he same, ha is, he curves jus shifed horizonally. For example, wih he deadline ranges beween 6-9 ms he success raio of boh proporional and individual allocaions drop o % when he baseline compuaion ime is 4 ms, whereas wih he deadline ranges beween 3-6 ms, hey drop o % when he baseline compuaion ime is only 2.8 ms. These resuls indicae ha deadlines of hard real-ime asks significanly affec he upper bound of he mulimedia server compuaion ime and hey are almos proporional. In Figure 9, resuls are shown where he execuion ime of hard real-ime asks is chosen from he differen ranges. The doed line shows he ranges beween -2 ms, he plain line -3 ms, and he dashed line -4 ms. Alhough he CPU loads in hose hree cases are almos he same because of he ask generaion procedure, he success raio varies sig- Success Raio (%) Success Raio (%) 8 6 4 2 2 proporional, deadline=6-9 individual, deadline=6-9 proporional deadline=3-6 individual deadline=3-6 3 4 5 6 Baseline mulimedia compuaion ime (ms) Figure 8. Effec of deadline on success raio. 8 6 4 2 2 proporional, size -2 individual, size=-2 proporional, size=-3 individual, size=-3 proporional, size=-4 individual, size=-4 3 4 5 6 Baseline mulimedia compuaion ime (ms) Figure 9. Effec of hard real-ime ask size on success raio. nificanly. In oher word, granulariy of he hard real-ime asks largely affecs he schedulabiliy. In his scheduling approach, he scheduling of he mulimedia server insances is fairly igh because he deadline of each insance is relaively shor. For example, when he period of he server is 33 ms and is compuaion ime is ms, he laxiy of he server is only 23 ms. When he maximum size of he hard real-ime asks is 4 ms (he dashed line), i is difficul for hem o fi in beween he server insances. In he figure, he success raio is only 55% wih proporional allocaion and 3% wih he individual allocaion when he server s compuaion ime is ms (i corresponds o 2 ms compuaion ime for he baseline mulimedia sream). These simulaion resuls have shown he sensiiviy of he success raio o he size of hard real-ime asks. Degradaion of Mulimedia QoS. The ieraive improvemen approach discussed in Secion 4 was also evaluaed wih simulaions. Here, he server raio Rs is adjused oward he highes value afer every scheduling aemp, ha is, when he n h scheduling aemp is successful, Rs for he (n + ) h aemp is increased o (Rs + upper bound)=2 and when i is no successful, Rs is decreased o (lower bound + Rs)=2. For each generaed ask se, his scheduling aemp was ieraed 9 imes and Figure shows he average success raio over 5 ask ses 6 simulaion runs achieved wihin n aemps for each ask se. As we can see in Figure, all he firs scheduling aemps in he simulaions failed. (The success raio = %
when he ieraion coun =.) For 78% of he generaed ask ses, he second scheduling aemp (he firs ieraion) succeeded. The figure shows ha for all he ask ses, he scheduling succeeded wihin 4 ieraions. In Figure, he Y axis is he degradaion raio r which indicaes he degree of degradaion from he iniial requesed QoS. r is defined as degraded Rs used in he nex ieraion iniial Rs (applicaion requiremen) (r = % means ha he server was no degraded a all.) The ploed degradaion raio were obained by averaging he highes Rs which gave successful schedules in he n ieraions. The resuls show ha we can ge significan improvemen in he server raio wihin several ieraions. In Figure, we show how close he ieraion scheme comes o he minimum loss in mulimedia service ha is possible due o he presence of hard real-ime asks. The dashed horizonal line in Figure indicaes he upper limi of he degradaion raio. From he figure we see ha he achieved raio ges fairly close o his limi. A more elaborae ieraive approach may be able o ge a higher degradaion raio, bu i will require a larger number of ieraions. In summary, he resuls show ha he scheduler can provide a feasible schedule wihin a few ieraions wihou decreasing he mulimedia compuaion ime oo much. 5.5. Influence of Conex Swich Overhead So far our resuls were based on he assumpion ha conex swich overheads are negligible. Here we discuss he effecs of conex swiching. The individual allocaion scheme allocaes an enire mulimedia ask insance o a single mulimedia server insance, and hence does no add any exra conex swiching overheads. The proporional allocaion sraegy allocaes a periodic mulimedia sream o a mulimedia server wih same or smaller period by dividing is periodic ime allocaion across muliple server periods. This mehod of servicing a single mulimedia ask insance in muliple disjoin ime inervals requires he sysem o swich he insance in and ou muliple imes before i ges is full allocaion. The associaed addiional conex swiching overhead due o his fragmenaion consiues an addiional load on he sysem. However, his overhead is a funcion of he period lenghs and is consan over differen mulimedia workloads for a given period lengh disribuion of he mulimedia sreams. Assume here are n mulimedia asks in he sysem. Task i, i n has period P i and esimaed wors case execuion ime per period is L i. The ime o swich a ask in or ou is a fixed C s. Le U mm be he of- Success raio (%) Degradaion raio (%) 8 6 4 2 2 3 4 5 Ieraion coun n Figure. Ieraion coun and he success raio. 8 78 76 74 72 7 68 66 2 3 4 5 6 7 8 9 Ieraion coun n Figure. Ieraion coun and he degradaion raio. fered mulimedia load o he sysem, and U inpu he associaed overhead of swiching each ask insance in and ou once during is period. Le U ovhd be he addiional conex swiching overhead inroduced by he proporional allocaion mehod. Le U cs be he oal conex swiching overhead P a he end of he server P allocaion phase. Then, n n U mm = i= Li P ; U i inpu = i= 2Cs P ; U i cs = P n i= 2Cs P server, where P server = min n j= (P j): Therefore, U ovhd = U cs? U inpu = 2 C s [ n P? P server n i= P i ]: U cs, he oal conex swiching overhead for proporional allocaion, is consan for a fixed number of mulimedia sreams and a given server period. U inpu is maximum = U cs if all he periods are idenical and decreases as he period lenghs diverge. U ovhd is minimum (i.e., equal o zero) if all he periods are idenical and increases as he period lenghs diverge. If he lenghs are similar, here is less fragmenaion of ask insances and he conex swiching overhead U ovhd is low. If he period of a mulimedia sream is much larger han he period of he smalles sream (i.e., he period of he mulimedia server), hen, his allocaion sraegy causes more fragmenaion and he number of inroduced conex swiches is larger. The percenage of addiional conex swich overhead caused by proporional allocaion depends only on he relaive lenghs of he periods of he differen 6 2