Using User Hints to Guide Resource Management for ... - CiteSeerX

Using User Hints to Guide Resource Management for Quality of Service Michael J. Katchabaw, Hanan L. Lut yya, and Michael A. Bauer Department of Computer Science The University of Western Ontario

Abstract

1 Introduction In today's computing environments, providing users with the level of quality of service they expect is becoming increasingly dicult. The typical environment is widely distributed, consisting of hundreds or thousands of heterogeneous computing nodes, and is growing in both size and diversity at a rapid pace. Applications in these environments are becoming larger, more complicated, and multimedia in nature, yet they must still co-exist with more traditional applications for transaction processing, data processing, and software development. Increasingly, these settings are playing mission critical roles in the enterprise, and their quality of service is essential. Indeed, users are demanding levels of performance, reliability, and availability comparable to those on traditional centralized systems, where quality of service problems are smaller, better contained, more readily identi ed, and easier to resolve. Consequently, meeting the quality of service expectations of users is becoming a considerable challenge for today's administrators. In recent years, signi cant strides have been made towards the speci cation and provisioning of quality of service [4, 5, 6, 8, 9, 10, 11, 12, 15, 17, 18, 19, 26, 27, 31, 34, 37, 40, 44, 45, 46, 49, 50, 51]. As noted in [47], \The human user of a multimedia application is the starting point for overall QoS considerations". Much of the work in this area recognizes this, and to varying degrees of success, aim to provide quality of service to meet user expectations. However, none of these approaches to quality of service capture where the interests of users truly lie or what users are actually doing with their applications|applications that are not in use or that are essentially being ignored by the user are still allocated and scheduled resources whereas applications that are the focus of user interest and activity can suer [1]. When one considers the amount of processor, memory, disk, network and other resources consumed by applications that are not being used by users and are being ignored in favour of other applications, there is a very signi cant waste of resources. Not only does this waste the money spent on these resources, but this also adversely impacts the quality provided by other applications contending for these scarce resources. These problems occur despite, and usually because of, the resource allocation and scheduling mechanisms designed to prevent them, especially when mechanisms allocate and schedule resources statically, as many existing quality of service solutions do.

Today's computing environments are becoming more and more distributed in nature. At the same time, the applications used in these environments are becoming more complicated and are being used in more mission critical roles in the enterprise. Consequently, users' demands for performance, reliability, and availability are increasing rapidly. To meet these needs, a high level of quality of service must be delivered to the user. Doing so, however, is not an easy task. Applications that are the focus of user interest and activity should be favoured in resource allocation and scheduling to provide the best possible quality, as opposed to those applications which are essentially ignored by the user. Fortunately, users often provide hints of their interest and activity through interactions with their windowing environments or applications directly. For example, applications that users are not attending to tend to get minimized or covered over on the window desktop in favour of those on which the user is focusing. Unfortunately, essentially all existing quality of service solutions are not receptive to these user hints|with all applications having the same rights to quality and resources regardless of whether or not the user is giving any attention to them. This results in resources being wasted and spread thin over some applications unnecessarily, and quality expectations for other applications not being satis ed. To address these problems, we have developed a quality of service management system capable of detecting and making use of these user hints to guide resource management, based on our previous work in this area. We present our general strategy, the design of a solution realizing this approach, and a preliminary prototype implementation based on this architecture. We describe experimentation and experience to date and evaluate our work and its eectiveness based on these preliminary results. Finally, we conclude with a summary of our work and outline our plans to evolve it in the future. [Keywords: User hints, dynamic resource management, processor scheduling, performance management, quality of service management] 1

Consider, for example, a user starts an application with quality constraints. To meet these constraints, the quality of service solution in place allocates or schedules the processor, memory, disk, video, and networking resources required, and ideally, the user is satis ed with the results. Now, suppose the user needs access to another application while the rst application continues executing. In a windowing environment, the user would typically minimize or cover the rst application to execute the new application, indicating the user's new interest in the new application, and relative lack of interest in the rst one. However, despite doing this, the rst application continues to use and drain available resources according to its quality of service speci cation, and the new application cannot satisfactorily execute. This is because the quality of service solution in place is completely unaware of the interests and actions taken by the user, and the frustration from being unable to execute new applications with any quality whatsoever. This scenario is not uncommon. In a survey we conducted sampling a variety of dierent categories of users using dierent windowing environments [25], we found that most users have between a half dozen and a dozen applications executing at any given time, with those applications not currently of interest either covered or minimized in their environment|this is, of course, the entire purpose of a windowing environment. Other studies and evaluations [2, 13, 20] echo these results, showing that users rarely complete any lengthy task before beginning another, resulting in multiple applications occupying the user's environment at once and a considerable amount of work switching the active window set (63% of all the operations in an independent windowing environment). These problems grow worse if the applications are not accessed from the local desktop, but rather from remote shared application or compute servers, where multiple users can more quickly drain resources. The problems that arise in both of these situations are further exacerbated by the fact that most users, when given the option, always choose to have the best quality of service from their applications, no matter where their true interests lie. Consequently, quality of service solutions trying to meet user expectations often run into great diculty and a serious lack of resources to meet requests. If the quality of service solutions in place, however, could determine what the interests of users really are, these problems would not be so severe, if they existed at all. Hints such as minimizing and restoring of windows, covering and uncovering of windows, and activation and deactivation of screen savers and locks are all excellent indicators of the interest users have in their applications and their resulting activity. Other more application-speci c indicators, such as a user turning down the volume of audio from an application, are also hints of user interest. If quality of service solutions were able to detect these hints from users, resources could be reallocated and rescheduled accordingly, taking them away from applications the user is not interested in, and giving them to applications currently the focus of the user's attention. This would reduce resource wastage

and provide resources to applications that truly need them. To date, there has been relatively little research and industrial eort investigating these problems. While these issues were raised in [1], no design or implementation work was ever completed. Research into multimedia applications such as [29, 30, 43, 48] and others has yielded adaptive applications capable of responding to user feedback (for example, by not transmitting audio streams when audio is muted by the user). Unfortunately, much of this work is domainspeci c and limited in scope, quite often only to reducing work done in response to user feedback, without deallocating and descheduling resources, which once again leads to problems. From industrial research, Microsoft Windows 95, 98, and NT [38] can capture some user hints to adjust application priorities and time quanta slightly as applications are foregrounded and backgrounded. Some avours of Unix have limited support for user hints, by adjusting scheduling according to I/O activity and so on, but this tends to be inadequate for responding to user hints in general. Consequently, there is much still to be done to address these issues. Our current work takes steps towards addressing the above problems by building upon our previous work in dynamic, end-to-end, application-driven quality of service management [22, 23]. This quality of service approach is end-to-end in that it supports quality of service on the endsystem, in addition to across intermediate nodes and the interconnecting networks. It is application-driven in that all expectations of quality of service are captured as policies (application-level speci cations of the constraints and conditions under which service is provided), and that the process of quality of service provision is based on application requests to change resource allocations to meet these policy expectations. Our current work focuses on extending this quality of service management solution to capture hints from application users that are indicators of user interest and activity. These hints are then used change or override application policies to guide the dynamic allocation and scheduling of CPU, memory, disk, video, and network resources in a distributed environment to applications that are the focus of user interest and activity. Doing so results in resource conservation, and improved quality of service delivery by user applications most in need. This, in turn, results in greater user satisfaction, the goal of quality of service management. In this paper, we begin with a set of requirements for quality of service solutions to meet to support the capturing and use of user hints. This is followed by an outline of the general approach taken in our work, and introduce an architectural framework that realizes this approach. We describe a preliminary prototype system based on this design work capable of adaptive and selective allocation of CPU cycles to applications based on user hints, and present experimental results and evaluations demonstrating the suitability of our system to its task. The paper concludes with a project status report and our plans for future work. 2

2 Requirements

3 A Model for Quality of Service Resource Management

Capturing and making use of hints from application users places several requirements on a quality of service solution that intends to take advantage of them to guide resource management. These requirements include the following:  A technique is needed to specify user hints and how they eect quality of service provision. A policy-driven approach would be quite suitable.  Mechanisms are required to detect user and application activity to indicate user interest and direct resource management. Transient activity and events should be ltered appropriately to avoid unnecessary and potentially disruptive resource reallocation and rescheduling.  The user hints considered must include not only general hints applicable in a wide variety of situations, but also application-speci c hints, as dierent applications many need to be treated dierently in response to user hints. For example, a video playback application may require minimal or no resources when it is minimized by the user. However, a web browser may be minimized by the user while it is retrieving a document over the network| taking all of its resources away so it cannot download the document in the background would not at all re ect the user's intentions and expectations. On the other hand, if the browser is not downloading a document, its resources may be safely taken away so they are not wasted on animations or applets in which the user currently has no interest.  The quality of service solution must be dynamic, and utilize dynamic resource management techniques. A static approach would not be responsive to user interests and activity, and could not reschedule or reallocate resources as needed.  The approach taken to quality of service must be \endto-end" and encompass all systems, network links, and software components involved. For example, if a video on demand client is no longer of interest to the user and minimized, not only should local host resources be rescheduled and reallocated, but so should networking and server resources used to support video delivery to that client.  The quality of service solution should not require users or application developers to have detailed knowledge of the resources and resource scheduling and allocation techniques in use. Instead, quality of service must be dealt with at the application level, with the underlying details eectively hidden by the quality of service solution. These requirements, unfortunately, rule out many of the quality of service solutions listed in Section 1. The quality of service solution developed as part of our previous work in this area [22, 23], however, is quite suitable. Extensions to it to support user hints to guide resource management are discussed in the remainder of this paper.

As previously mentioned, we have developed a model for resource management that supports end-to-end applicationdriven quality of service and utilizes dynamic resource management techniques [22, 23]. In this section, we rst discuss the general strategy taken in our model, and then describe an architectural design that realizes this strategy. Extensions to this approach to support capturing and making use of user hints to guide resource management are discussed in the following section.

3.1 Overall Strategy

The general strategy in our model, shown in Figure 1, is to dynamically adjust the resource allocations given to an application until the quality of service it delivers meets expectations. These expectations can be defaults selected by application designers, preferences chosen by the application user, or corporate policies set by administrative personnel. If the delivered quality of service exceeds expectations by a large margin, the application could do with a less generous resource allocation. On the other hand, if the delivered quality of service is below expectations, the application requires a better resource allocation, either through the allocation of additional resources, or a better distribution of previously allocated resources. This approach is similar to that suggested in [3, 14, 35]. Given: Application p.

Initial resource allocation a. QOS metric m. QOS expectations e.

1. p is started with resource allocation a. 2. while (p not done) do: 3. Execute code in p. 4. q QOS measured with m. 5. if (q > e) then 6. Determine allocation reduction r. 7. a a - r. 8. else if (q < e) then 9. Determine allocation improvement i. 10. a a + i. 11. endif 12. endwhile Figure 1: Application-Driven Resource Management Strategy This approach has several advantages. No assumptions are made about the metrics used to measure delivered quality of service, so virtually any metric can be used, provid3

3.2.1 Instrumented Process

ing it is measurable within a program, including: frames of media processed per second, application responsiveness, transactions processed per second, data loss, synchronization, jitter, and so on. Since application-level metrics can be easily used, the details of how quality is provided are eectively hidden from the user and application developers by the underlying quality of service solution. The dynamic nature of this approach adjusts resource allocations until only those resources needed to meet user expectations are allocated, resulting in user satisfaction, reduced resource wastage from overallocation, and side-stepping dif cult quality of service mapping problems [5]. This dynamic nature also allows quality constraints and expectations to change while the application and quality of service solution are executing. Finally, this approach makes no assumptions of the underlying system architecture, network, operating system, or resource allocation schemes in use, and will work as long as there is a way to adjust resource allocations dynamically, whether that is done through changing execution priorities, rates, periods, time slices, delays, bandwidth, or whatever underlying approach is used. As a result, this approach is portable to a wide variety of systems and scheduling paradigms. Further details can be found in [22, 23]. From the above advantages, we can see that this approach meets many of the requirements presented in Section 2, and provides all of the necessary support to eectively make use of user hints. In the next section, we examine how this approach can be realized for practical use.

An instrumented process is an application process with embedded instrumentation code. It is this instrumentation code that enables the management of the application process. The architecture components that comprise the instrumentation code are discussed below. Coordinator. The coordinator facilitates interactions between the resource manager and the instrumented process. Its role includes message routing, managing sensors and actuators, and handling initialization and termination activities within the process. All knowledge of the resource manager is con ned to this component, eectively hiding it from the remaining instrumentation components. Sensors. Sensors are used to collect, maintain, and (perhaps) process a wide variety of metric information within the instrumented processes. Sensors get their input data from probes inserted at strategic points in the application code or by reading other sensors. Sensors provide their information to the coordinator in the form of periodic reports, alarm reports (when exceptional or critical circumstances arise), or in response to explicit requests. Sensors are dynamic components|they can be enabled or disabled, reporting intervals can be adjusted, thresholds can be modi ed, and sensor processing algorithms can be changed, all at run-time while the application process is executing. By instrumenting processes with the appropriate sensors, application-level quality of service metrics, such as those described in Section 3.1, can be easily collected from executing processes. Specifying application-level quality of service expectations can be done by rst formalizing expectations in terms of policies, using some high-level policy speci cation language [28], perhaps presented to the user in some graphical format. These policy speci cations can be translated into thresholds which are supported by the sensors in our architecture. Consequently, by detecting when these thresholds are violated within sensors, we are able to determine when the quality of service delivered by an instrumented application deviates from expectations. Actuators. Actuators are used to encapsulate functions that can exert control over the instrumented process to change its operation or behaviour. Actuators, like sensors, function through the use of probes or other actuators, and possess similar dynamic properties. In this current work, they are not used extensively, but can be used to support quality of service negotiation, adaptation, and other functions in the future. Probes. Probes are embedded in process code to facilitate interactions with sensors and actuators. Probes allow sensors to collect metric information and allow actuators to exert control over process behaviour. Each probe is speci c to a particular sensor or actuator. Probes are the only instrumentation component that must be injected into the original process source code|all other components need only reside in the same address space as the process, and do not require code modi cations.

3.2 Architectural Design

Having identi ed a strategic approach in Section 3.1 that meets our general objectives, we focus in this section upon the software architecture that will support this approach. To support our strategic approach, we have developed the architecture shown in Figure 2. This architecture is derived from our earlier work in application instrumentation [21]. This approach requires the insertion of code into applications at strategic locations to facilitate the collection of quality of service metrics and exertion of control over the applications. While some measurements can be taken by observing external application behaviour and rudimentary control can be achieved through operating system interactions, work in this area has found that these approaches are limiting in both accuracy and the kinds of metrics and control available. Since these limitations are unacceptable for quality of service management, instrumentation is the only option. The end-to-end application-driven resource management architecture we have developed is object-oriented: Classes of standard components can be developed for general tasks and new components can be specialized easily from existing standard classes. This allows application developers to reuse components easily to reduce development eort, while allowing them to build application-speci c components tuned to their particular needs. The components of this architecture are discussed in the sections below. 4

Quality of Service Resource Management System

Interactions

Instrumented Instrumented ... Process 1 Process n

Coordinator S

Original Process

A Legend

A

S

Sensor

A

Actuator

S

Probe

Figure 2: Application-Driven Resource Management Architecture

3.2.2 Quality of Service Resource Management System

underlying system and resource scheduler or manager.

3.2.3 Detailed Example

A quality of service resource management system, or simply a resource management system, is a collection of applications responsible for managing a set of resources, such as CPU cycles, memory, network and disk bandwidth, and so on. This includes allocating and scheduling the resources, as well as accounting for their use. A resource management system can be structured as single or multiple resource manager processes spread throughout a distributed environment. A resource management system can be tightly coupled or integrated with an end-system operating system, or it can be independent of the system software. How exactly the resource management system is structured, and how responsibilities for resources and applications are assigned to individual resource manager processes are completely open. One can imagine a hierarchy of resource manager processes working with one another to manage the resources of a large distributed environment. When an instrumented process is not meeting quality of service expectations, its coordinator will notify the resource management system to adjust resource allocations so that these expectations can be met. To do so, the resource management system must determine where in the distributed environment changes are needed, which resources should have their allocations changed, and how much the allocations should be changed. The adjustments carried out by the system depend upon the application making the noti cation, the resources in question, the allocation and scheduling paradigms used, and the underlying system and network architecture. Since we make no assumptions on how the adjustments are made, this architecture can support any

In this section, we present an example showing how the general strategy of Section 3.1 is carried out through the components of the architecture described in this section. In this example, we will consider the instrumentation and use of a video application whose pseudo-code shown in Figure 3. Given: Video application v. QOS policy p.

1. 2. 3. 4. 5. 6. 7. 8. 9.

Perform initialization for v. Initialize coordinator c. Initialize frame rate sensor r with p. Create window w for displaying video. while (v not done) do: Retrieve next video frame f. Decode and display f in w. Execute r ! probe.

endwhile

Figure 3: Instrumentation Example We start by taking the video application process and instrumenting it using the components described above. It is then executed in an environment with a resource management system with an initial resource allocation. We assume that there is a quality of service manager application 5

4 Supporting User Hints

on each host that changes CPU allocations to instrumented processes. We then specify quality of service expectations for this application in a policy using application-level metrics. In this example, suppose that the user speci ed a policy p that the application deliver video at a frame rate of 25 frames per second, plus or minus 2 frames. At this point, we have the initial conditions outlined in the strategy in Figure 1, and can proceed with carrying out this approach. The application is started with its initial resource allocation. At this time, a coordinator c for the process is also created and a frame rate sensor r is initialized. At this point, the quality of service policy p is translated into initial thresholds for the frame rate sensor r. In this example, the policy from above will translate into a threshold specifying a target rate of 25 frames per second, an upper threshold of 27 frames per second, and a lower threshold of 23 frames per second. Once initialized, the application retrieves video frames, decodes them, and displays them in a window w created by the application. After each frame is processed, a frame rate sensor probe is called, as shown on line 8 of Figure 3. The sensor r measures the time since the last probe invocation, and uses this value to determine the current frame rate, ltering out noise and unusual spikes in the measurements. If the given quality of service policy p is violated, the sensor r will notify the coordinator c. The coordinator c will, in turn, notify the resource management system of the situation to have resource allocations adjusted appropriately. For example, if the delivered frame rate increased to 30 frames per second, the frame rate sensor r will generate a report to have the rate decreased, which would nd its way to the resource management system. The resource management system determines a resource allocation reduction or redistribution to move the application's delivered quality of service into line with policy expectations in p, and makes the necessary adjustments. If, on the other hand, the delivered frame rate dropped to 20 frames per second, the frame rate sensor r threshold is violated and the sensor generates a report to have the frame rate increased. The resource management system determines a resource allocation improvement to move the application's quality of service into line with policy expectations p, and makes the necessary adjustments. This improvement could entail either the allocation of additional resources, or a redistribution of previously allocated resources. At this point, either the application v has met policy expectations p, or adjustments were made to do so. This procedure repeats as long as the process continues to execute, bringing the quality of service provided closer and closer to policy expectations. The design presented in this section eectively realizes the general approach introduced in the previous section. In the next section, we examine how this approach can be extended to incorporate hints from application users.

In the previous section, we presented a dynamic, end-toend, application-driven approach to quality of service management that meets the requirements from Section 2 necessary for a quality of service solution to support capturing and making use of user hints. In this section, we present the extensions to this approach necessary to detect indicators of user activity and interest and make use of them to guide resource management. Doing so meets the remaining requirements from Section 2.

4.1 Detecting User Hints

To detect hints of activity from application users, we need a mechanism that can collect and process this information from within a program. This mechanism should be reusable in a variety of scenarios for both generic purposes, common to most applications, and application-speci c purposes, to meet the needs of particular applications. This mechanism must also provide ltering to prevent unnecessary reactions to transient user activity. As can be seen from Section 3.2, sensors instrumented into applications can meet all of these needs without diculty. Quality of Service Resource Management System Reports

User

Coordinator

Coordinator

Reports

Reports

S

S

S

Events

S Events

Application Events

Windowing Environment

Actions

Signals, System Call Returns

Operating System Interrupts

Hardware

Figure 4: User Activity Event Flow To illustrate how user hint sensors can detect user activity, consider the following event ow, shown in Figure 4. When users carry out tasks at a workstation, they interact with the workstation through a variety of peripheral hardware devices such as a keyboard or mouse. Actions such as typing or mouse movement generate hardware interrupts that get processed by the device drivers of the operating 6

system of the workstation. The environment the user application executes in, most likely a windowing environment of some kind, receives notice of the user activity in the form of a signal or a returning system call. This environment could be integrated with the operating system, depending upon the platform in question. User applications that are the target of the user activity may then receive notice of this activity in the form of events from the environment. User hint sensors instrumented into the user applications either collect events through probes inserted into the applications, or by subscribing to the windowing environment to receive copies of the events using a standard event noti cation pattern [39]. Since the windowing environment might be executing on a dierent host than the user application, the events propagated by the windowing environment might pass through a variety of networking links and components en route to the user application and user hint sensors. The sensors then process the events, lter them, and generate reports to their coordinator, which in turn edits and forwards the reports the quality of service resource management system. The resource management system takes the reports, and uses them to guide resource allocations appropriately. To support user hints common to a wide variety of applications, generic classes of user hint sensors can be developed. To support more application-speci c user hints, additional user hint sensor classes can be easily added or derived from the generic base classes, as mentioned in Section 3.2. For example, a generic windowing user hint sensor can be developed to detect user activity such as covering and uncovering windows, minimizing and restoring windows, and so on. These user hints are common and useful to a variety of applications. As another example, application-speci c user hints sensors would be useful for applications playing audio and video media|hints such as stopping or pausing playback, muting audio, and so on are all excellent indicators that resources could be reallocated to other applications1. Having a variety of user hint sensors is essential to detect the user activity needed to eectively guide resource management. For user hint sensors to be completely effective, however, we must be able to tune their behaviour as well. For example, only a subset of the hints that a sensor can detect may apply to a particular application, transient activity may need to be ltered dierently by different applications, and the reactions made to various user hints may be dierent for dierent applications|in some applications, a particular user hint should result in a reallocation of resources, whereas in other applications, the same user hint should not result in such a reallocation (for example, a partially obscured window might be acceptable for some applications, but not for others). As mentioned in

Section 3.2, policies are used to specify sensor thresholding and behaviour. The same policy mechanism can be used to specify the behaviour of user hint sensors. This includes the types of hints the sensor should detect, how transient activity is ltered, as well as how the sensor should react to detected hints. Since all sensor behaviour can be changed dynamically, how user hints are detected and processed can be changed at run-time to match changes in speci ed policies. Furthermore, user hint sensors can be disabled and reenabled as all sensors can to temporarily or permanently suspend the detection and processing of user hints, if necessary.

4.2 Handling User Hints

As mentioned in Section 3.2, a quality of service resource management system makes resource management decisions based on reports received from instrumented applications. These reports originate from application sensors to ensure that their quality of service policies are being met by the application. Consequently, for hints of user interest and activity to guide resource management, user hints must result in changing or overriding these policies. For example, if a video-on-demand application was given a policy to play video at a rate of 25 frames per second, reports from the application's sensors will have the resource management system in place dynamically allocate the resources required to have the policy met. If the playback window becomes obscured, this user hint indicates a lack of interest in the application and that its resources could be reallocated elsewhere. With the application's current policy in place, this reallocation would not be possible as the frame rate would drop and violate the policy. Consequently, this policy must be overriden temporarily until another user hint indicates otherwise. Overriding policies to handle user hints can be done in a simple fashion. When a process coordinator receives a report from a user hint sensor indicating that resources should reallocated and rescheduled elsewhere, the coordinator rst disables all other sensors with quality of service policies in place, eectively overriding the policies. With the sensors disabled, they can no longer submit reports to have their resources adjusted by the quality of resource management system in place. However, resources are still currently allocated and scheduled by the resource management system to meet those policies. Consequently, the process coordinator issues a report to the resource management system, which rst records the current allocation of resources to the application in question, and then reallocates the resources to other applications in need. Likewise, when a process coordinator receives a report from a user hint sensor indicating that resources should be allocated and scheduled to the application once again, the coordinator reenables all sensors that were previously disabled, eectively reinstating their quality of service policies. The coordinator issues another report the the resource management system, which restores the original allocation and schedule of resources to

1 It is important to note that while some actions taken in applications, such as those listed in this example, will reduce the work done by the application and consequently the demand placed on available resources, resources may still not be deallocated. This is particularly the case when previous quality of service speci cations forced these allocations in the rst place, which contributes to the resources wasted by many quality of service solutions, as mentioned in Section 1.

7

5 Prototype Implementation

the application. As a result, user hints can be handled quite eectively to guide resource management decisions. With the above extensions to our previous work in this area, hints of user interest and activity can be detected and used to improve resource management decisions to better supply quality of service. In making these extensions, we satisfy the remaining open requirements from Section 2.

In this section, we describe a prototype system we have developed based on the approach and architecture presented in the previous sections. This prototype has been implemented for Solaris, and has already been partially ported to AIX and Windows NT2 . Additional porting eorts are currently under way.

4.3 Revisiting the Detailed Example

5.1 Instrumentation Implementation

We now go back to the video application example presented in Section 3.2.3, and incorporate the detection of handling of user hints. The new pseudo-code for the video application is shown in Figure 5.

Instrumentation is provided to application developers through a C++ class library. This library contains a variety of standard sensors, actuators, and coordinators. Probes for sensors and actuators are provided as methods on these objects which are inserted into application source code to be executed along with the application code, or periodically through a timer. In our class library, we provide sensors capable of measuring frame rates of delivered media, transaction processing rates, computational processing rates, interactive response times, and data loss, as well as a coordinator for our resource management system (discussed below). User hint sensors have been provided to detect and handle generic windowing environment hints in an X Windows environment (window covering and uncovering, window minimizing and restoration, screen saver and lock activation, and so on) as well as application-speci c hints in video applications (audio muting, video stoppage or pausing, and so on). The library can also be further specialized to develop new classes of instrumentation components to meet the unique needs of speci c applications. This is done through providing a variety of abstract classes suitable for specialization. Further implementation details of our instrumentation and code examples can be found in [21, 22, 23].

Given: Video application v. QOS policy p.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Perform initialization for v. Initialize coordinator c. Initialize frame rate sensor r with p. Initialize generic window sensor g. Create window w for displaying video. Register w with g to detect user hints. while (v not done) do: Retrieve next video frame f. Decode and display f in w. Execute r ! probe.

endwhile

Figure 5: Instrumentation Example with User Hints Supporting user hints requires only the addition of a new generic window sensor g. When the video display window w is created, it is registered to this new sensor so that whenever w is the target of user hints, these hints are detected and processed. If the window w is obscured from view, by the user covering it with another window, minimizing it, or activating a screen saver or lock, these user hints are detected by the sensor g, which noti es the coordinator c. The coordinator and resource management system override the quality policy p by disabling the frame rate sensor r, and allocating the video application's resources to other applications. If the video window is later made visible again, by the user uncovering it, restoring it, or deactivating the screen saver or lock, g once again detects these hints and noti es the coordinator c. The coordinator and resource management system restore the quality policy p by reenabling the sensor r, and reallocating resources back to the application. By detecting and processing these hints, the video application only consumes resources when it is the focus of user interest and activity, reducing resource wastage and assisting in providing quality to other applications in need.

5.2 Resource Manager Implementation

As proof of concept, we have developed a simple resource management system capable of dynamically changing resource allocations to instrumented processes. As mentioned previously, we are focusing on handling CPU allocations on a single system in our initial work. This was done for several reasons: 1. Working with one resource initially allows us to concentrate on the dynamic application-driven aspects of our work, as well as the detection and handling of user hints. 2. CPU allocations on a system have been shown to have a major impact on application quality of service [24, 32], so examining this resource rst is appropriate. Consequently, this approach to an initial prototype marks a very sound rst step|we are currently developing support for additional resources, including memory and net2 Prototype source code and pre-compiled binaries can be made available upon request.

8

work bandwidth, as well as support for managing and coordinating the resources of multiple systems [22, 23]. The approach in this prototype is to develop a user-level CPU resource management system, as was done in [5, 19]. The resource management system is structured as a single resource manager daemon process executing at the highest possible real-time priority on the system [41]. Essentially, this means that the manager will execute whenever it is in a runnable state. This, along with locking it into memory, provides excellent responsiveness. (We could also execute the manager at the highest possible time-sharing priority available, with a slight cost in responsiveness.) Instrumented processes communicate with the resource manager using semaphores and shared memory registered at the initialization of the processes. When the quality of service delivered by a process deviates from its policies, a sensor threshold is violated. The sensor computes how far it is from its target level of quality, and passes this on to the coordinator for the process. The coordinator takes this value and signals the resource manager using semaphores to inform the system of the need for a resource allocation adjustment. Similarly, when user hints are detected by user hint sensors, the coordinator signals the resource manager using semaphores to reallocate resources appropriately, depending on the user hint detected. In our initial prototype, the resource manager adjusts allocations dynamically through changes to the time-sharing priorities assigned to processes using the priocntl() system call. When the coordinator for an instrumented process noti es the resource manager that it is not meeting quality of service expectations, the system will increase or decrease the time-sharing priority for the process, depending upon whether the process was not meeting or exceeding expectations respectively. The amount of increase or decrease is proportional to how far a process is away from meeting expectations|the further away, the larger the adjustment. Thus, as an instrumented process executes, its time-sharing priority will be dynamically adjusted, moving the process towards the CPU allocation necessary to meet, but not exceed, quality of service expectations. If a window hint is detected indicating that the process should lose resources, the resource manager saves the current priority of the process and sets its priority below the level given to other processes3 ; likewise, when a hint is detected indicating that the process should regain its resources, the resource manager restores its priority to the previously saved value. The time-sharing approach taken in this initial prototype was for two key reasons: 1. This approach is the simplest to use in an initial prototype. This would allow us to focus on the dynamic application-driven aspects of our work, as well as the detection and processing of user hints, as opposed to the implementation of a more complex and sophisticated

real-time scheduling paradigm. We would not need to worry about process starvation or detecting when instrumented processes block in the kernel (e.g. waiting for I/O), which were identi ed as potential hazards in [19]. 2. Most operating systems support time-sharing priorities, whereas only a few provide stable and reliable support for real-time priorities. This would allow us to target our initial prototype at several platforms with minimal porting costs. Recognizing that a time-sharing approach to quality of service is not a good long-term solution, as the literature has shown time and time again, we have designed the resource manager to support real-time scheduling algorithms proposed by other researchers such as rate monotonic and others in the future, and we are currently working on adding this support to our prototype. With such algorithms, the resource manager would dynamically adjust execution time slices, rates, periods, and so on. The instrumented processes, however, would not be aected at all by such changes. The prototype implementation described in this section is a solid proof of concept of our general approach to the problem at hand. In the next section, we present experimental results and evaluations that exercise this prototype, thereby demonstrating the utility of our quality of service management solution in detecting and processing user hints to guide resource management for quality of service.

6 Experimental Results and Experience An initial set of experiments was conducted to evaluate the operation of the prototype discussed in the previous section. Based on the success of these tests, more rigorous experiments were planned and executed. The results of these experiments proved to be quite interesting, demonstrating the utility, exibility, and suitability to task of our work. All of the experiments discussed in this section were carried out using a Quality of Service Management Testbed developed as part of our previous work in this area [24]. This section presents results from experimentation with our quality of service management system extended to support user hints. The experiments discussed in this section focus on the use of the Berkeley MPEG video player [36], as a considerable portion of the literature in this area uses this as a test application. This section also provides results from experiments making use of other applications such as Netscape's Mozilla/Navigator web browser [7], Id Software's popular game DOOM [16], a video capture utility [42], and several desktop utilities. These experiments demonstrate that our new quality of service management system improves resource management and, consequently, quality of service provided by this variety of applications

3 It is important to choose this value wisely to avoid noticeable delays in restoring quality to the process, while still conserving as many resources as possible. Experiments are under way to determine the optimal value.

9

quality of service policy, with the remaining resources used by the X server and other system processes. When a duplicate video player was executed with the same workload and policy to meet, the allocation of resources to the rst video player was split almost exactly in half, with the other half allocated to the new player. Obscuring (minimizing or covering) the rst player had no impact on CPU usage when user hints were ignored. However, when user hints were not ignored and used by the quality of service management system, obscuring the rst player resulted in a reallocation of CPU resources from the rst player to the second, corresponding to the user's interest in the two players. With user hints in place, only a fraction of CPU resources, approximately 0.35%, remained with the rst player. This is a signi cant improvement, since over 43% of CPU resources are consumed unnecessarily by the rst player when user hints are ignored|a tremendous waste of a valuable and scarce resource. Further experimentation with other applications revealed similar resource wastage and possibilities for resource conservation through user hints. A single instance of Id Software's game Doom at 960x600 resolution, for instance, was found to consume approximately 89% of the CPU resources on an UltraSparc 1 workstation, whether or not the game was visible to the user. A single instance of Netscape's Mozilla/Navigator displaying a web page with the only active content being a small 80x80 pixel animated GIF image was found to consume 25% of the CPU resources on an UltraSparc 1 workstation, even when obscured5 . A video capture utility capturing a 320x240 8-bit MPEG stream on an UltraSparc 1 workstation was found to consume almost 100% of CPU resources, even when obscured. On an RS/6000 220 workstation, various desktop utilities (including a clock and other tools) were found to consume approximately 15% of CPU resources, despite having the workstation locked with no one at the console. In all of these cases, when user hints were not ignored, CPU resources were reallocated to other processes in need on the system, and the CPU wastage by the above applications was minimized. As the above experimental results have shown, taking advantage of user hints can save a substantial amount of resources and reallocate them to other processes in need. Otherwise, these resources would be wasted on applications that are not the focus of user attention and activity.

100

90

80

Average CPU Usage (%)

70

60

50

40

30

20

10

0 One Video

Two Videos

Video 1

Video 2

Two Videos, First Obscured, User Hints Ignored X Server

Two Videos, First Obscured, User Hints Not Ignored

Other

Figure 6: Video Playback CPU Analysis through taking advantage of indicators of user interest and activity4.

6.1 Resource Allocation and Scheduling Results

We began our experimentation with the Berkeley MPEG video player, as discussed above, taking the latest available version, version 2.3, and instrumenting it. To monitor its performance, we added a sensor to measure its video playback throughput, in frames per second. We also added a sensor to monitor generic windowing environment user hints indicating user interest and activity. The resulting program was executed on one of our UltraSparc 1 workstations using Solaris 2.5.1 and our resource manager to assist in dynamically scheduling the application. We instructed the player to display a 352336 8-bit video le from disk, and we gave it a quality of service policy dictating that it play the video with a mean frame rate of 16 frames per second, allowing for a deviation of 2 frames per second from this target (giving a range of 14 to 18 frames per second). Our experimentation consisted of executing the instrumented video player several times while ensuring the workstation was otherwise idle and isolated from other users. Experiments were replicated ve times for statistical con dence. Figure 6 shows the CPU usage of the UltraSparc 1 workstation in the video player experiments, measured using the top utility. When only one video player was executing, it consumed the bulk of CPU resources (87%) to meet its

6.2 Quality of Service Provisioning Results

Having seen that user hints can lead to better resource allocation to applications in need, the experiments discussed 5 As an interesting note, while this paper was being written on another UltraSparc 1 compute server in our department, the server strained under the load of another Netscape Navigator browser consuming over 87% of the CPU resources while the owner of the process was away for the weekend with his screen saver blanked out, locking his terminal. Needless to say, the authors would have been much more satis ed with their own applications if his had not been ignoring user hints!

4 Experimentdata sets, including workloads and raw results, as well as testbed tools can be made available upon request.

10

18

100

90

16

80 14

70

Average Video Jitter (%)

Average Video Throughput (FPS)

12

10

8

60

50

40

6 30

4 20

2

10

0

0 One Video

Two Videos

Video 1

Two Videos, First Two Videos, First Obscured, User Hints Obscured, User Hints Ignored Not Ignored

One Video

Video 2

Two Videos

Video 1

Two Videos, First Obscured, User Hints Ignored

Two Videos, First Obscured, User Hints Not Ignored

Video 2

Figure 7: Video Playback Throughput Analysis

Figure 8: Video Playback Jitter Analysis

in this section demonstrate how this, in turn, leads to improved quality of service provisioning by those applications. Figure 7 compares the mean video playback throughput, in frames per second, for the Berkeley MPEG video player under a variety of circumstances. First, we can see that with only one player on the system, our quality of service policy was maintained by the system without any diculty. When the second video player was introduced with the same workload and quality policy, neither could meet expectations, and the frame rate delivered was less than half of the desired level. Obscuring the rst video player with user hints ignored had no impact on the quality provided, and our expectations were once again not met. However, when user hints were not ignored and were used by the quality of service management system, we can see that when the rst video player was obscured, that resources allocated to the rst player were freed, and reallocated to the second player. This resulted in the second player meeting its quality of service policy, with the rst player performing worse than before, acceptable since it was no longer the focus of the user's attention and activity. As indicated in [33], the variance of the playback rate, or jitter, can have a more signi cant impact on perceived quality of service than merely the rate alone. Using the testbed, another analysis was carried out using the same approach to experimentation; this time, measuring the jitter in the time required to display each frame of video. Figure 8 shows the mean jitter measured under the same sequence of experiments as above. For these experiments, jitter was computed as the ratio between the mean variation in display time and the mean display time, to normalize results. As can be seen from Figure 8, jitter increased substantially

with the introduction of the second video player, and was not reduced when the rst player was obscured from view and these user hints were ignored. When user hints were detected and used to guide resource allocation as above, the increase in jitter to the second video player, the focus of user interest, was minimized. Jitter observed from the rst video player increased as its resources were reallocated to the other player, but this was again acceptable since the rst player was obscured and of little interest to the user at that time. Further experimentation with user hints and the video player produced similar results. After being obscured, if the rst video player was later made visible, video throughput and jitter immediately returned to the levels previously observed with both players executing at the same time. If the second video player was then obscured, the rst player received the same quality gains enjoyed by the second player when the rst was obscured in our earlier experiments above. The above experiments were repeated using our other instrumented applications including Netscape's Navigator, Id Software's DOOM, the video capture utility, and several desktop utilities. Experiments with these applications produced results similar to those for the Berkeley MPEG video player. As a result, we can conclude that our quality of service management system can take advantage of user hints and reallocate resources to applications to minimize resource wastage and maximize the bene ts to the user obtained from the resources. This translates into improved quality of service provisioning where it is truly needed the most by the user. 11

6.3 Prototype Performance Results

 We need to continue to discover additional generic hints

from users that indicate their interest and activity. We also need to continue investigating new hints for speci c applications and how dierent hints should be handled for dierent applications.  It is important to continue our work to support additional resources distributed across multiple hosts, as well as our porting eorts to dierent platforms.  We also need to continue studies into optimizing resource consumption to determine how many resources can or should be taken away from applications in response to various user hints. Since, as stated in Section 5, we cannot safely take all resources from an application, we need to nd the largest amount possible to minimize wastage. Through this work, we have gained valuable insight into the quality of service management problem. With this experience, we can further pursue solutions that eectively and completely address the variety of quality of service problems that occur in today's computing environments.

Having demonstrated that our prototype system can make use of user hints to improve resource management for quality of service, we still need to assess the performance of the system to determine what the cost of the system is, and how well it works. From measurements taken during experimentation, the overhead cost from our approach is minimal. An instrumented process on our UltraSparc system requires approximately 400 microseconds more time to initialize itself and report to our resource manager. One pass through the instrumentation code to take a quality measurement requires only 11 microseconds on average when the coordinator does not need to contact our resource manager. On the other hand, whenever the resource manager must be contacted, because a user hint was detected or a quality policy was violated, the instrumentation takes on average 474 microseconds to submit a report the violation to our resource manager, and to have it make appropriate priority adjustments. This is acceptable, since the alternative is even more costly in terms of wasted resources or inadequate quality provision. From additional experimentation conducted with users, we found that resources were reallocated and rescheduled so quickly that the time taken for quality of service to meet user expectations was imperceptible. As applications executed, quality provisioning was prompt and stable. When users gave hints of their interest and activity, resources were reallocated to the new focus of interest before any quality problems were visible to the user. As a result, we can conclude that the prototype system carried out its task well, and at a minimal cost. For further analyses and results involving the prototype system, please consult [22, 23].

References [1] M. Alfano. Design and Implementation of a Cooperative Multimedia Environment with QoS Control. Computer Communications (21), Elsevier Science, Fall 1997. [2] L. Bannon, A. Cypher, S. Greenspan, and M. Monty. Evaluation and Analysis of Users' Activity Organization. Proceedings of the 1983 ACM Conference on Human Factors in Computing Systems, Boston, Massachusetts, December 1983. [3] K. Brown, M. Mehta, M. Carey, and M. Livny. Towards Automated Performance Tuning for Complex Workloads. Proceedings of the 20th International VLDB Conference, 1994.

7 Concluding Remarks The work we describe here is part of ongoing work on addressing issues in quality of service management. This paper focuses on the integration of hints of user interest and activity into the quality of service management process. Based on a set of basic requirements, we developed an approach to detect and make use of these indicators in a dynamic quality of service management system. Using a prototype system based on this approach, we have been able to carry out a number of experiments that demonstrate that, if captured and used correctly, user hints can be a very successful guide to resource management. Doing so had been shown to reduce resource wastage and improve the quality of service provided by applications that are truly the focus of user attention. We have identi ed several avenues for continuing and future work in this area:  We plan to continue instrumenting applications and experimentation to further validate our work.

[4] S. Chen and M. Thapar. I/O Channel and Real-Time Disk Scheduling for Video Servers. Hewlett Packard Labs Technical Report HPL-96-126, August 1996. [5] H. Chu and K. Nahrstedt. A Soft Real Time Scheduling Server in UNIX Operating System. European

Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services, Darmstadt,

Germany, September 1997.

[6] H. Chu and K. Nahrstedt. Memory Management for Soft Real-Time Multimedia Applications. Technical Report, University of Illinois at Urbana Champaign, October 1997. [7] Netscape Communications Corporation. Mozilla Technical Documentation. On-line Documentation from http://www.mozilla.org, June 1998. 12

[8] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Speci cation. Internet RFC 1883, December 1995. [9] L. Delgrossi, R. Herrtwich, and F. Homann. An Implementation of ST-II for the Heidelberg Transport System. Proceedings of the 1992 IEEE Globcom Conference, Orlando, Florida, 1992. [10] P. Druschel. Operating System Support for High-Speed Networking. PhD thesis, The University of Arizona, August 1994. [11] D. Engler, M. Kaashoek, and J. O'Toole Jr. Exokernel: An Operating System Architecture for ApplicationLevel Resource Management. Proceedings of the Fifteenth Symposium on Operating Systems Principles, December 1995. [12] D. Ferrari, A. Banerjea, and H. Zhang. Network Support for Multimedia. Technical Report TR-92-072,

[21] M. J. Katchabaw, S. L. Howard, H. L. Lut yya, A. D. Marshall, and M. A. Bauer. Making Distributed Applications Manageable Through Instrumentation. Journal of Systems and Software, In Press for 1999.

[13] K. Gaylin. How are Windows Used? Some Notes on Creating an Empirically-Based Windowing Benchmark Task. Proceedings of the 1986 ACM Conference on Human Factors in Computing Systems, Boston, Massachusetts, April 1986. [14] L. Georgiadis, C. Nikolaou, and I. Viniotis. Adaptive Scheduling Algorithms that Satisfy Average Response Time Objectives. IBM Research Report RC 14851 (#66555), August 1989. [15] P. Goyal, X. Guo, and H. Vin. A Hierarchical CPU Scheduler for Multimedia Operating Systems. Proceed-

[25] M. J. Katchabaw and G. Molenkamp. A Survey of Windowing Environment Usage Patterns. Unpublished

[22] M. J. Katchabaw, H. L. Lut yya, and M. A. Bauer. Driving Resource Management With ApplicationLevel Quality of Service Speci cations. To Appear in the Proceedings of First International Conference on Information and Computation Economies, Charleston,

South Carolina, October 1998.

[23] M. J. Katchabaw, H. L. Lut yya, and M. A. Bauer. A Model for Resource Management to Support End-toEnd Application-Driven Quality of Service. To Appear

in the Proceedings of the Tenth International Conference on Parallel and Distributed Computing Systems,

Las Vegas, Nevada, October 1998.

[24] M. J. Katchabaw, H. L. Lut yya, and M. A. Bauer. A Quality of Service Management Testbed. Proceedings

The International Computer Science Institute, Berkeley, California, November 1992.

of the Third IEEE International Workshop on Systems Management, Newport, Rhode Island, April 1998. Survey, Department of Computer Science, The University of Western Ontario, July 1998.

[26] C. Lee, R. Rajkumar, and C. Mercer. Experiences with Processor Reservation and Dynamic QOS in RealTime Mach. Proceedings of Multimedia Japan, March 1996. [27] I. Leslie, D. McAuley, R. Black, T. Roscoe, P. Barham, D. Evers, R. Fairbairns, and E. Hyden. The Design and Implementation of an Operating System to Support Distributed Multimedia Applications. IEEE Journal on Selected Areas in Communications, June 1997.

ings of the Second Symposium on Operating Systems Design and Implementation, Seattle, Washington, Oc-

[16] [17] [18]

[19] [20]

tober 1996. Id Software Inc. DOOM. December 1997. K. Jeay and D. Bennett. A Rate-Based Execution Abstraction for Multimedia Computing. Lecture Notes in Computer Science 1018:64-78, 1995. M. Jones, J. Barrera III, A. Forin, P. Leach, D. Rosu, and M. Rosu. An Overview of the Rialto RealTime Architecture. Proceedings of the Seventh ACM SIGOPS European Workshop, September 1996. J. Kamada, M. Yuhara, and E. Ono. User-level Realtime Scheduler Exploiting Kernel-level Fixed Priority Scheduler. Multimedia Japan, March 1996. E. Kandogan and B. Shneiderman. Elastic Windows: Evaluation of Multi-Window Operations. Proceedings

[28] D. Marriott, M. Mansouri-Samani, and M. Solman. Speci cation of Management Policies. Proceedings of the Fifth IFIP/IEEE International Workshop on Distributed Systems: Operations and Management,

Toulouse, France, October 1994.

[29] S. McCanne and V. Jacobson. LBNL Audio Conferencing Tool (vat). On-line Documentation from http://www-nrg.ee.lbl.gov/vat, December 1996. [30] S. McCanne and V. Jacobson. vic: A Flexible Framework for Packet Video. Proceedings of ACM Multimedia '95, November 1995. [31] C. Mercer, S. Savage, and H. Tokuda. Processor Capacity Reserves: Operating System Support for Multimedia Applications. Proceedings of the IEEE Interna-

of the 1997 ACM Conference on Human Factors in Computing Systems, Atlanta, Georgia, March 1997.

tional Conference on Multimedia Computing and Systems, Boston, Massachusetts, May 1994.

13

[32] K. Nahrstedt and J. Smith. An Experimental Investigation of Issues in End-to-End QoS. Technical Report MS-CIS-94-08, DSL 76, University of Pennsylvania, Februrary 1994. [33] J. Nieh, J. G. Hanko, J. D. Northcut, and G. A. Wall. SVR4UNIX Scheduler Unacceptable for Multimedia Applications. Proceedings of the Fourth Inter-

[46] C. Venkatramani and T. Chiueh. Design, Implementation, and Evaluation of A Software-Driven Real-Time Ethernet Protocol. Proceedings of the 1995 ACM SIGCOMM Conference, Cambridge, Massachusetts, August 1995. [47] A. Vogel, B. Kerhevre, G. V. Bochmann, and J. Gecsei. Distributed Multimedia Applications and Quality of Service: A Survey. Proceedings of the 1994 Centre for Advanced Studies Confererence, Toronto, Canada, November 1994. [48] J. Walpole, R. Koster, S. Cen, C. Cowan, D. Maier, D. McNamee, C. Pu, D. Steere, and L. Yu. A Player for Adaptive MPEG Video Streaming Over The Internet. Proceedings of the 26th Applied Imagery Pattern Recognition Workshop, Washington DC, October 1997. [49] F. Wang, C. Wen, C. Cheng, M. Lee, T. Lin, S. Wang, and Y. Oyang. Memory and Disk Bandwidth Management in Video-on-Demand Servers. Proceedings of

national Workshop on Network and Operating System Support for Digital Audio and Video, Lancaster, Eng-

land, November 1993. [34] J. Nieh and M. Lam. The Design, Implementation and Evaluation of SMART: A Scheduler for Multimedia Applications. Proceedings of the Sixteenth ACM Symposium on Operation Systems Principles, St. Malo, France, October 1997. [35] C. Nikolaou, D. Ferguson, and P. Constantopoulos. Towards Goal Oriented Resource Management. First Workshop on Load Balancing on High Performance Parallel and Distributed Systems, June 2, 1995.

the Sixth International Workshop on Network and Operating System Support for Digital and Audio Video,

[36] K. Patel, B. Smith, and L. Rowe. Performance of a Software MPEG Video Decoder. Proceedings of the 1993 ACM Multimedia Conference, Anaheim, California, August 1993. [37] M. De Prycker. Asynchronous Transfer Mode. Ellis Horwood, New York, 1996. [38] J. Richter. Advanced Windows, Third Edition. Microsoft Press, 1997. [39] D. Riehle. The Event Noti cation Pattern|Integrating Implicit Invocation with Object-Orientation. Theory and Practice of Object Systems 2, 1, 1996. [40] I. Stoica, H. Abdel-Wahab, K. Jeay, S. Baruah, J. Gehrke, and C. Plaxton. A Proportional Share Resource Allocation Algorithm for Real-Time, TimeShared Systems. Proceedings of the Real-Time Systems Symposium, Washington, DC, December 1996. [41] Sun Microsystems Inc. Multithreading and Real-Time in Solaris: A White Paper. Mountain View, California, 1992. [42] Sun Microsystems Inc. SunVideo User's Guide. Mountain View, California, August 1994. [43] Sun Microsystems Inc. The Complete Guide to ShowMe 2.0.1. Mountain View, California, May 1994. [44] H. Tokuda, T. Nakajima, and P. Rao. Real-Time Mach: Toward a Predictable Real-Time System. Proceedings of USENIX Mach Workshop, October 1990. [45] C. Topolcic. Experimental Internet Stream Protocol, Version 2 (ST-II). Internet RFC 1190, 1990.

Zushi, Japan, April 1996. [50] D. Yau and S. Lam. Adaptive Rate-Controlled Scheduling for Multimedia Applications. Proceedings of the 1996 ACM Multimedia Conference, Boston, Massachusetts, November 1996. [51] L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala. RSVP: A New Resource Reservation Protocol. IEEE Network Magazine, 9 (5), September 1993.

14