A Soft Real-tie Scheduling Server on the Windows NT Chih-han Lin, Hao-hua Chu, Klara Nahrstedt Departent of Coputer Science University of Illinois at Urbana Chapaign clin2, h-chu3, klara@cs.uiuc.edu Abstract We present the design and ipleentation of a soft real tie CPU server for the tie-sensitive ultiedia applications in the Windows NT environent. The server is a user-level daeon process fro which ultiedia applications can request and acquire periodic processing tie in the well-known for of (processing tie per period). Our server is based on a careful anipulation of the real tie(rt) priority class, and it does not require any odifications to the kernel. It provides () the rate onotonic scheduling algorith, (2) support for ultiple processors (SMP odel), (3) liited overrun protection aong realtie(rt) processes, (4) fair allocation between the RT and tie sharing (TS) processes so that TS processes are not starved for processing tie, (5) accessibility by a noral user privilege, and (6) an efficient ipleentation. We have ipleented the CPU scheduling server on top of the Windows NT 4. operating syste with dual Pentiu processors, and we have shown through experients that our CPU scheduling server provides good soft real tie support for the ultiedia applications.. Introduction Continuous edia processing, such as video/audio copression/decopression, and 3-D rendering and aniation, are becoing widely-used applications on coputers nowadays. To preserve their teporal behavior, ultiedia applications require that the underlying systes provide sufficient and periodic processing tie and enforce quality guarantees to the users (e.g. a fixed video playback rate). However, in the Windows NT ulti-process and tie-sharing environent, these ultiedia applications do not perfor well when they are scheduled concurrently with the traditional TS applications such as text editors, copilers, web browsers, or coputation-intensive jobs. Oftenties, the proble lies in untiely scheduling of the processes rather than insufficient processor capacity. This paper addresses this proble and presents a user-level iddleware solution on top of the Windows NT operating syste with ultiple processors. There have been several research results that address the issues of accoodating scheduling of soft RT processes in general purpose operating syste environent. They are the Constant Utilization Servers[2], the Processor Reserve of the RT Mach[8,6], the Hierarchical CPU scheduler[4], the User-level Real Tie Scheduler[7], the Real Tie Upcall[3], the Rate- Controlled Scheduling[], the Soft RT scheduling Server[9], the Rialto operating syste[5], the Neesis[], and the SMART syste[]. All except [] are based on the general concepts of reservation, resource allocation, and scheduling. The RT process first sends a reservation request, which specifies its resource deand, e.g., RT Mach convention of (requested CPU usage tie, period), to the resource anager. Then the resource anager perfors an adission control to deterine if there is enough available resource to allocate for this request. If the adission control test succeeds, the RT process is scheduled according to the reserv ation contract. Our scheduling echanis is based on the user-level RT scheduler(ursched) proposed by Kaada[7] in UNIX. The URSched echanis is based on the POSIX.4 fixed priority extension and its priority scheduling rule. The user-level scheduler is ipleented on top of the kernel scheduler, and it runs at the highest possible fixed-priority. The RT process waits its turn at the lowest possible priority (called the waiting priority), and the active RT processes run at the 2 nd highest fixed priority. The user-level scheduler wakes up periodically to dispatch the RT processes by oving the between the waiting and the running priority; during the other tie, it just sleeps. When the scheduler sleeps, the RT process executes at the running priority. When no RT processes are dispatched, the TS processes with dynaic priorities are scheduled by the underlying kernel scheduler. This approach has shown to have any desirable prope rties:
It requires no odification to the kernels. The RT scheduler is ipleented as a user-level process. It has low coputation overhead. It provides the flexibility to ipleent any scheduling algoriths in the user-level scheduler, e.g., rate onotonic, earliest deadline first, or a hierarchical scheduler. The above discussed scheduling echanis was used and further expanded by additional echaniss, algoriths, and policies in our QoS-aware resource anageent iddleware [9], called QualMan. In this context, the iddleware is understood as a syste software between operating syste and applications that provides access to extended and flexible OS services, e.g. real tie support, to applications without any odifications of the operating systes. Our iddleware provides the following ser vices : Rate Monotonic Scheduling algorith. Overrun Protection aong RT processes. Fair allocation between the RT and TS processes. Access to syste services with noral user privileges. Based on lessons learned fro the soft RT scheduling server in the UNIX environent, we design, ipleent, and test the soft real-tie scheduling server in the Windows NT environent. In addition, we provide support for scheduling of RT and TS processes on ultiple processors. The paper is organized as follows: section 2 explains the scheduling server architecture; section 3 describes the ipleentation on the Windows NT platfor, and discusses the differences between UNIX and the Windows NT operating syste; section 4 shows the experiental results; section 5 presents the concluding rearks. 2. Server Architecture and Design Our server architecture contains three ajor coponents the broker, the dispatcher, and the dispatch tables as shown in Figure. A RT Client is an external coponent representing an application which requests the scheduling services fro the scheduling server. because they play an iportant role in our architecture and design. Each NT process or its ain thread has a scheduling priority. Each thread s priority is deterined by the priority class of its process and the priority level of the thread within the priority class of its process. Note that our scheduler is a process scheduler and it does not schedule the various threads in each RT process. There are four possible priority classes for a process: IDLE_PRIORITY_CLASS 2 NORMAL_PRIORITY_CLASS 3 HIGH_PRIORITY_CLASS 4 REALTIME_PRIORITY_CLASS There are seven possible priority levels within each priority class: THREAD_PRIORITY_IDLE 2 THREAD_PRIORITY_LOWEST 3 THREAD_PRIORITY_BELOW_NORMAL 4 THREAD_PRIORITY_NORMAL 5 THREAD_PRIORITY_ABOVE_NORMAL 6 THREAD_PRIORITY_HIGHEST 7 THREAD_PRIORITY_TIME_CRITICAL 2. Client RT Process A RT process can reserve a certain aount of CPU tie fro the real-tie scheduling server. At a later tie, it can also free or odify a reservation through an application progra interface (API) defined in Table. The client s reservation request contains the process ID and its resource specification in the for: period=p(s), and CPU usage in percentage=u. The aount of CPU tie per period, denoted E, is coputed as E = U*P. For exaple, if a RT process requests a reservation for CPU usage = 3%, period = s, and the request is accepted by the scheduling server, then the scheduling server will guarantee that the RT process is scheduled for 3s of CPU tie every s, given that the RT process is runnable. Before we describe each coponent in detail, we discuss the priority levels in the Windows NT syste
Write Dispatch Table Read Broker Dispatcher Request RT Client Process Dispatch Figure : The Soft RT Server Architecture Table : Application progra interface int Cpu::reserve(int pid, double util, int period) Reserve CPU tie corresponding to util over the tie period for the process pid. Return / for resource adission su ccess/failure. int Cpu::freeReserve(int pid) Free the reservation hold by process pid. Return / for success/failure. double Cpu::getAvailResource() Return the aount of available CPU resource in the syste. int Cpu::odifyReserve(int pid, double newutil, int newperiod) Modify the reservation held by process pid. Return / for resource adission success/failure. The users start the RT process at the NOR- MAL_PRIORITY_CLASS which is like any other Tie Sharing (TS) processes. When the RT process calls the CPU reserve() API, it opens an inter-process counication (IPC) with the broker through which the reserve paraeters and the acceptance result are exchanged. To address the security proble which one process can odify or free another process s resource reservation through the API, the broker perfors an ownership check to ake sure that the calling process can be peritted to change the resource reservation of the specified RT process. Then the broker and the dispatcher schedule the RT process by anipulating its priority, the echanis is described below. 2.2 Broker and Dispatch Table The broker receives requests fro the client RT processes. It perfors an adission control test for the non-preeptive rate onotonic scheduling algorith [2] to deterine whether the new client RT process can be scheduled. Note that all equations ust be satisfied for the adission test to succeed. Given a total of periodic RT processes and a single processor syste (N=), let the RT processes be sorted according to sizes of their periods. Let e i and p i be the execution tie and the period of the i-th client RT process, e and p be the execution tie and period of the RT process with the sallest period, and r be the overall percentage of processor capacity allocated to the RT processes. e i r N (eq. ) i = p i p e + ax ( i < ) e (eq. 2) i p e + ax (, ) e + e F ( p e, p ) (eq. 3) i i j j i j j i j j j = i + x w here F ( x, y ) = ceil( ) + y Given an N processors syste, the broker needs to decide how to place the ultiple RT processes into the ultiple processors. The broker aintains a set of RT processes that are aditted and are assigned to run on each of the processors. The set of processes for each processor ust satisfy both eq. 2 and 3. When a new RT process request arrives, the broker tries to place the new RT process in each of the processors (..N) by perforing the above one-processor adission trial on the processor. During the one-processor adission trial, the new process is inserted into the existing set of processes corresponding to that processor, and eq. 2 and 3 are checked. If the trial succeeds, the broker will adit the new RT process which is assigned to that processor. If the trial fails, the broker will try to place the new RT process in the next processor. If the broker cannot find any processor that can accoo-
date the request, the RT process is rejected and not schedulable. If it is schedulable, the broker will put the RT process into the waiting RT process pool by changing its priority to the waiting priority at IDLE_PRIORITY_CLASS level. The broker is a daeon process running at a noral priority (The server s priority class is NOR- MAL_PRIORITY_CLASS and the priority of its priary thread is THREAD_PRIORITY_NORMAL). It can be started at the syste boot tie. It will wake up when a new client RT process request arrives. The broker needs to be run with the privilege of LocalSyste (equivalent to the root privilege in UNIX) so that it can start a RT process. The broker process does not perfor the actual dispatching of the RT processes and does not enforce reservations. However, it needs to start (at the startup tie) the dispatching process. The reason for separation between the broker process and the dispatcher process is that the adission and schedulability test in the broker ay have variable coputation tie, hence it ay affect the tiing of dispatching. The other reason is that the adission and schedulability tests do not need to be done in real tie. As a result, the broker runs at a noral priority and the dispatcher at a higher RT priority. The broker coputes its schedule for the RT processes in its dispatch table using the non-preeptive rate onotonic algorith. The dispatch table is a shared eory object where the broker writes the coputed schedule into it and the dispatcher reads fro it. The dispatch table contains a repeatable tie frae of slots, each slot corresponds to a tie slice of a processor. Each slot can be assigned to a RT process PID, or is free which eans yielding the control to the NT kernel scheduler to schedule TS processes. Note that Windows NT allows the syste to have ultiple processors in a syetric ultiprocessing odel (SMP). Given N processors, we can run N processes concurrently. Therefore the dispatch table has N coluns of repeatable tie slots, where the i-th colun corresponds to the schedule on the i-th processor. We show a saple dispatch table for a dual processors syste in Table 2. Note that it is possible that the broker ay ake a assive change to the dispatch table when accepting a new RT process, while the dispatcher is dispatching tie slots located at iddle of a tie frae. This assive change ay cause undesirable shifts in the rate onotonic schedule and ay disrupt the guaranteed tie slots assigned to soe RT processes. As a result, the dispatcher will keep a separate private copy of the dispatch table which it uses for dispatching. This private copy of the dispatch table is only updated with the broker when the dispatcher reaches the end of its tie frae. Table 2: A saple dispatch table for a dual processors syste. Slot Nuber Tie Process PID Process PID -2s 2 2-4s 3 2 4-6s 2 3 6-8s free free 4 8-s 2 5-2s free 3 6 2-4s 2 7 4-6s free free The repeatable frae in Table 2 has a length of 6s, and it contains 8 tie slots of 2s each. The saple dispatch table is a result of a rate onotonic schedule, where process is assigned to run on processor # and according to the contract (period=4s, execution tie=2s), process is assigned to run on processor # and according to the contract (period=6s, execution tie=2s), process 2 is assigned to run on processor #2 and according to the contract (period=4s, execution tie=2s), and processor 3 is assigned to run on processor #2 and according to the contract (period=8s, execution tie=2s). There are 4 free slots where TS processes can run. The iniu nuber of free slots is aintained by the broker to provide a fair share of the CPU tie to the TS processes. In the above dispatch table, a total of 3.25% (s out of possible 32s) of processing capacity is guaranteed to the TS processes. The site adinistrator can adjust this TS allocation value, which is (- r) in the adission control equations, to be what is considered as a fair allocation between the TS and RT processes. For exaple, if the coputer is used heavily for RT applications, the TS allocation value can be set to a sall percentage nuber. 2.3 Dispatcher The dispatcher is a periodic process running at the highest possible fixed priority with (REALTIME_PRIORITY_CLASS +THREAD_PRIORITY_TIME_CRITICAL). The
dispatcher aps the dispatch table into its address space, and its job is to dispatch the RT process recorded at the tie slot for all the processors. The dispatcher contains the next slot nuber. At the beginning of each dispatch slot, a periodic RT tier signals the dispatcher to schedule the next RT process. The length of tie to switch fro the end of one tie slot to the beginning of the next tie slot is called the dispatch latency. The dispatch latency is our scheduling overhead and it should be kept at a inial value. Consider the saple dispatch table in Table 2 at 2 s when the next slot nuber is. The following steps are taken by the dispatcher:. The periodic tier wakes up the dispatcher process at 2s. The dispatcher preepts RT process (or 2) if it is running on processor (or 2). 2. The dispatcher sets the RT processes and 2 to the waiting priority (IDLE_PRIORITY_CLASS) using the syste call SetPriorityClass(). 3. The dispatcher prootes the RT processes and 3 to the running priority (REALTIME_PRIORITY_CLASS). It binds the RT processes /2 to processors #/#2 using the syste call SetProcessAffinityMask(). 4. The dispatcher puts itself to sleep. As a result, the RT processes /2 are scheduled on processors #/#2 for 2s until the tier wakes up the dispatcher again. We have encountered a proble in the Windows NT that the periodic tier ay fail to wake up the dispatcher when the RT process overruns its assigned slot. Overrun is defined as an additional tie to the reserved processing tie of an aditted RT process. Take the exaple of process in Table 2 and it has reserved 2s out of every 6s. It would be overrunning when it uses ore than 2 s of processing tie (say 3s) to coplete one iteration run. When an overrun occurs, the invocation of the dispatcher will be delayed till the RT process finishes its overrun due to the tier proble. This eans that one process overrun can delay the dispatching of the process in the next tie slot. Hence, until we resolve the preeption tier proble in Windows NT, we assue wellbehaved RT processes. In the eantie, the dispatcher takes two actions to control the overrun. The first one is that the dispatcher will onitor for any isbehaving RT processes that are overrunning on a regular basis and it will reove the. We currently define a isbehaving process as one that is overrunning for ore than 2% of its reservation and for ore than 3 iterations during the ost recent iterations. Take the exaple of process in Table 2. It would be isbehaving if during the ost recent iteration runs, it uses ore than 24s (which is 2% ore than the 2s reservation) of processing tie for ore than 3 ties. The paraeters that define a isbehaving process can be set by the syste adinistration to be either ore strict or lax. The second action is that the dispatcher will use soe of the TS allocation, by teporarily assigning the free slots to the RT process whose tie slots are taken by overrunning RT processes. 3. Ipleentation We have ipleented our server architecture on a HP Vectra Xu syste which has two Intel Pentiu 2 processors and 96M of eory. It runs Windows NT 4. operating syste. The dispatch latency consists of 4 SetPriorityClass() syste calls, 2 SetProcessAffinityMask() syste calls, and 3 context switches. The average dispatch latency, over, runs, is easured as.64 s. The tie slot is set to be 2s, and the overhead coes to be 3.2%. 4. Experiental Result The experient consists of the following load of applications running concurrently: The MPEG player, written by MSSG (MPEG Software Siulation Group), plays a 32x24 MPEG- file twister.pg that contains a clip of the ovie Twister at 2 fraes per second (FPS). The sae MPEG player plays a second 32x24 MPEG- file lecture.pg that contains a speaker giving a lecture, at 2 fraes per second. The Microsoft Visual C++ Copiler copiles the MSSG MPEG player. Four copute progras calculate the sin and cos tables using the infinite series fo rula.
35 3 25 2 5 5 twister (NRT) 35 3 25 2 5 5 lecture (NRT) 79 73 82 89 98 79 73 82 89 98 35 3 25 2 5 5 twister (RT) 35 3 25 2 5 5 lecture (RT) 79 73 82 89 98 79 73 82 89 98 Figure 2: The inter-frae tie for the MPEG player that plays the twister.pg and lecture.pg files at 2 fraes per second. The y axis easures the inter-frae tie in s, and x axis shows the frae nubers. The top two graphs show the result for the Windows NT kernel scheduler, and the botto two graphs show the result for our scheduling server with processor reservation for the twister.pg at (%, 5s) and lecture.pg at (8%, 5s). The graphs in Figure 2 show the easureent of interfrae tie on the MPEG player under the above specified load. The top two graphs show the result for the twister.pg (upper left) and lecture.pg (upper right) under the Windows NT scheduler without our scheduling server. The botto two graphs show the result for the 2 FPS twister.pg (lower left) with % processor reserve every 5 s, and the 2 FPS lecture.pg (lower right) with 8% processor reserve every 5s. The twister.pg playback requires ore processor tie because it contains lots of action with rapid oving background, whereas the lecture.pg playback contains slow oving action with alost no changes in background. Using the Windows NT scheduler, jitter over 2s (equivalent to 4 fraes tie) occurs frequently for both MPEG video. Using our scheduling server, jitter over 2s does not occur at all. 5. Conclusion Our experients validate the design and ipleentation of the soft real-tie scheduling server for continuous edia processing. Our contribution is that under the control of our scheduling server within the Windows NT environent, () RT processes obtain a desired aount of CPU tie to satisfy soft real-tie requireents; (2) RT processes are onitored and protected against overruns of other RT processes; (3) RT processes have access to tiing QoS guarantees and systes services with noral user privileges; and (4) TS processes get a iniu aount of CPU tie and do not starve. References. Richard Black, Paul Barha, Austin Donnelly, Neil Stratford. Protocol Ipleentation in a Vertically Structured Operating Syste. IEEE LCN, Nov. 997. 2. Z. Deng, J.W.-S. Liu, J. Sun. Dynaic Scheduling of Hard Real-Tie Applications in Open Syste Environent. Technical Report No. UIUCDCS-R-96-98, Departent of Coputer Science, University of Illinois at Urbana-Chapaign, Oct. 996. 3. R. Gopalakrishnan. Efficient Quality of Service Support Within Endsystes for High Speed Multiedia Networking. PhD Thesis, Washington University. Dec. 96.
4. Pawan Goyal, Xingang Guo, Harrick Vin. A Hierarchical CPU Scheduler for Multiedia Operating Syste. The proceedings of Second Usenix Syposiu on Operating Syste Design and Ipleentation, Seattle WA, Oct 996. 5. Michael B. Jones, Daniela Rosu, Marcel-Catalin Rosu. CPU Reservations and Tie Constraints: Efficient, predictable Scheduling of Independent Activities. Proceedings of the 6th ACM Syposiu on Operating Systes Principles (SOSP '97), St. Malo, France, Oct. 997. 6. Chen Lee, Ragunathan Rajkuar, Cliff Mercer. Experience with Processor Reservation and Dynaic QoS in Real-Tie Mach. Multiedia Japan, 996. 7. Jun Kaada, Masanobu Yuhara, Etsuo Ono. User-level Realtie Scheduler Exploiting Kernellevel Fixed Priority Scheduler. Multiedia Japan, March 996. 8. Clifford W. Mercer, Stefan Savage, Hideyuki Tokuda. Processor Capacity Reserves: Operating Syste Support for Multiedia Applications '. IEEE International Conference on Multiedia Coputing and Systes. May 994. 9. Klara Nahrstedt, Hao-hua Chu, Srinivas Narayan. QoS-Aware Resource Manageent for Distributed Multiedia Application. Technical Report No. UI- UCDCS-R-97-23, Departent of Coputer Science, University of Illinois at Urbana-Chapaign, Oct. 996.. Jason Nieh, Monica La. The Design, Ipleentation and Evaluation of SMART: A Scheduler for Multiedia Applications. Proceedings of the Sixteenth ACM Syposiu on Operating Systes Principles, St. Malo, France, Oct. 997.. David K.Y. Yau and Sion S. La. Adaptive Rate-Controlled Scheduling for Multiedia Applications. ACM Multiedia Conference, Boston, MA, Nov. 996. 2. R. Nagarajan and C. Vogt. Guaranteed- Perforance Transport of Multiedia Traffic over the Token Ring. Technical Report 43.92, IBM European Networking Center, IBM Heidelberg, Gerany, 992.