Techniques for Implementing
Quality of Service
In the Eclipse, Nemesis and Real-Time Mach
Operating Systems
Francesca Ruffolo
December 6, 2001
Instructor: Dr. Marius Soneru
CS 550
Comparative Operating Systems
Table of Contents
Abstract: ......................................................................................................................................... 3
1.0
Introduction........................................................................................................................ 3
1.1
Eclipse Operating System .......................................................................................................... 3
1.2
Nemesis Operating System ........................................................................................................ 3
1.3
Real-Time Mach Operating System .......................................................................................... 4
2.0
Implementation of QoS in Operating Systems .................................................................. 4
2.1
Eclipse ........................................................................................................................................... 4
2.1.1
Reservations .............................................................................................................. 5
2.1.2
Tagging ...................................................................................................................... 5
2.1.3
Reservation Domains................................................................................................. 5
2.1.4
Quality of Service Parameters ................................................................................... 6
2.1.5
Move-to-Rear List Scheduling (MTR-LS)................................................................... 7
2.2
Nemesis......................................................................................................................................... 7
2.2.1
Quality of Service Manager ....................................................................................... 7
2.2.2
Run Time Resource Allocation .................................................................................. 8
2.2.3
Accounting ................................................................................................................. 8
2.2.4
Policing ...................................................................................................................... 9
2.3
Real-Time Mach ........................................................................................................................... 9
2.3.1 Processor Reserves ............................................................................................... 9
2.3.2
Dynamic QoS Server .............................................................................................. 9
2.3.3
Q-RAM (QoS-based Resource Allocation Model) ................................................... 10
3.0
Conclusions and Summary ............................................................................................. 12
4.0
Other Implementations of Quality of Service .................................................................. 12
5.0
References ...................................................................................................................... 13
2
Abstract:
The requirement to make quality of service (QoS) guarantees available is increasing with the
need to run multiple server applications, such as audio and video media servers, web servers,
and host services for multiple entities (organizations, individuals) on the same platform. This
paper evaluates and compares the techniques used to implement quality of service in three
separate operating systems: Eclipse/BSD, Nemesis, and Real-Time Mach.
1.0 Introduction
In order to support multiple real-time applications on a single platform, the operating system must
have the ability to reserve system resources among several applications in order to achieve a
certain level of performance. Although networks now provide quality of service guarantees with
respect to packet delay and bandwidth, these are of little value if they are not extended directly to
the application via the operating system.
The motivation for implementing quality of service (QoS) control in operating systems is to allow
explicit control over provisioning of system resources among applications to achieve desired
levels of predictable performance. In addition, quality of service is used to guarantee a certain
level of performance to server applications.
The quality of service initiatives requires the changing of current operating systems in the area
resource schedulers: CPU, disk (file systems), physical memory, and I/O.
1.1
Eclipse Operating System
Eclipse is a product of research that evolved from the Plan 9 operating system that was
developed by Bell Laboratories in New Jersey starting in the late 1980’s. Plan 9 was developed
in response to several trends in the computing industry at that time.


Networks of smaller, more personal machines were preferred over large centralized timeshared computers (typically UNIX workstations)
Administrators grew weary of overloaded, routine time-sharing systems and wished to
move to small, self-maintained systems
In the rush to accommodate customer’s needs via the creation of personal workstations,
weaknesses in doing so were overlooked. Plan 9 attempted to fix both problems.
 Graphics and networking that were added to UNIX in the latter part of its lifecycle were
poorly integrated
 The early focus on private machines made it difficult for networks to serve as seamlessly
as standard time-sharing systems.

1.2
The current version of Eclipse, often referred to as Eclipse/BSD (based on FreeBSD
(Berkeley Software Distribution) version 3.4), provides quality of service support for
applications. Eclipse is utilized for guaranteeing QoS to server applications and
distinguishing among performance of different web sites hosted on the same platform.
Nemesis Operating System
The Nemesis operating system results from work completed for the Pegasus and Pegasus II
projects. The following universities and corporation partnered together in order to develop
Nemesis:
 University of Cambridge, U.K.
 University of Twente, Netherlands
 University of Glasgow, U.K.
 Swedish Institute of Computer Science, Sweden
 Citrix Systems, LTD, U.K.
3
Both Pegasus and Pegasus II projects were based on the following:
 Use of generic multimedia platforms rather than single multimedia applications
 Integration of communication and processing
 Management of resources to provide quality of service guarantees
The design of Nemesis, which evolved from Pegasus and Pegasus II, was fully geared toward
support of time-sensitive applications requiring a consistent quality of service (QoS). Nemesis
provides guaranteed levels of system resources including: CPU, memory, network bandwidth and
disk bandwidth. Nemesis currently runs on a large number of platforms including Intel 486,
Pentium, PPro, DEC Alpha workstations, StrongARM SA-110 based network computers.
1.3
Real-Time Mach Operating System
Research into the Real-Time (RT) Mach system began in 1985. RT Mach is a real-time operating
system developed as a flagship product by the Real-Time and Multimedia Laboratory in
partnership with the Department of Computer Science at Carnegie Mellon University.
Real-Time Mach is a resource kernal which helps to satisfy end-to-end quality-of-service (QoS)
requirements. A resource kernal is defined to be one that provides timely, guaranteed and
protected access to system resources. The resource kernel allows applications to specify only
their resource demands leaving the kernel to satisfy those demands using hidden resource
management schemes.
Parts of the Mach Operating system have been incorporated into a number of commercial
operating systems including:






Encore’s Multimax
Next OS
MachTen for the Macintoshes
Omron’s Luna
DEC’s OSF/1 for the DEC Alpha
IBM-s OS/2 for the RS6000 based machines
Current research in RT Mach includes support for distributed resource management,
mechanisms for guaranteeing end-to-end delays and dynamic QoS control.
2.0 Implementation of QoS in Operating Systems
Each of the three operating systems (Eclipse, Nemesis, and Real-Time Mach) uses different
techniques in implementing quality of service guarantees.
2.1
Eclipse
In order to successfully implement quality of service in Eclipse, the operating system uses
techniques such as reservations, tagging, reservation domains, quality of service parameters and
the move-to-rear list scheduling policy.
4
2.1.1 Reservations
The developers of the Eclipse operating system design and implemented the /reserv
(reservation) file system which the operating system can access, use and reconfigure the system
resource schedulers. The directory nodes correspond to the nodes in the scheduler’s hierarchy
and thus represent reservations. The file system allows the addition and deletion of reservations
and the changing of schedule weights throughout. Each resource contains a reservation
directory, for example, the CPU is represented by /reserv/CPU. If a resource has more than one
reservation, it is split into /reserv/CPU/r1, /reserv/CPU/r2, etc.
2.1.2 Tagging
The design of the reservation also includes a connection with an operation on an object. Such
operations may include reading or writing to a file or executing a thread. Reservations, thus,
have references to objects so that the object can be shared without having to share reservations.
Thus, a “tag” is used to label a file descriptor. For example, for the cpu reservation, a tag is
provided for each process with a cpu reservation that allows a method of dynamically changing
the tag if needed. Tags and tagged file descriptors are used to determine the appropriate queue
for similar requests.
2.1.3 Reservation Domains
Access and admissions to the /reserv file system is offered via the reservation domain.
Reservation domains allow control over system resources among applications in order to achieve
a desired performance level. Reservation domains are assigned a certain fraction of each
resource. For example, a domain may contain 25% CPU, 50% disk I/O, 25% main memory).
Eclipse, therefore, uses reservation-domain scheduling of multiple resources such as CPU, disk
and physical memory. Processes that belong to a particular reservation domain are guaranteed
to attain at least their reservations portion of the domain’s associated resources. An example of a
system that has two reservation domains (RD1 and RD2) is shown in Figure 1. One or more
processes may run in a single reservation domain.
P1
R2
P6
R1
P2
P3
R1
RD1
RD2
Figure 1. Reservation Domain Systems
Reservation domains were designed in an attempt to merge the best attributes of real-time, timesharing, and stand-alone systems. The following are advantages of reservation domains that
cannot be achieved with previously used priority based or real-time based scheduling.
 Provides quality of service even in an overloaded system
 Enables division of resources according to a policy. Two resources may each reserve
half of CPU, although one resource may contain more processes than the other.
5

Provides efficient means of controlling the computing environment. The system provides
a resource “supervisor” that adapts resource reservations dynamically according to
processes issues. A lagging process will prompt the supervisor to increase its
reservations.
2.1.4 Quality of Service Parameters
The scheduling algorithm used by Eclipse, observes three parameters when evaluating priorities:
delay, fairness, and cumulative service. While several algorithms provide delay bound and
fairness parameters, cumulative service is fairly new. The following definitions are useful when
describing fairness, delay and cumulative service:


Di = Reservation Domain
ai = fraction of a resource allocated to a given reservation domain
Ideally each domain, Di should receive at least ai fraction of resource whenever Di has a process
that requires the resource.


Virtual service time = the minimum service time received in the idealized service model.
The virtual service time received by the domain in any real time interval (T, t) is denoted
by vi (T, t).
Real service time (running on the resource) = ai vi (T, t) = si (T,t)
Real scheduling policies require running at most one process at a time on the resource which
means that if there is more than one process waiting to run on a resource, then one or both
processes will experience a (queuing) delay.




Cumulative real waiting time = wi(T,t). This is the time obtained by Di during an interval
(T, t) where its process is blocked by other domains’ process running on the resource.
Total real time = si (T,t) + wi(T,t). This is the time spent by Di at the resource in the
interval (T, t) by running or waiting.
System: a collection of resources. Each resource is modeled by a service rate and preemption interval t . t is the minimum time a resource must run before a pre-emption
can occur. A resource with a zero pre-emption interval can preempt a process at any
time.
Phases: manner in which a process executes. A phase is resource duration pair (s,t),
where s is one the resources and t is the amount of time it takes for resource s to
complete the phase running alone on the resource.
 Fairness
The fairness parameter measures the ability of the system to ensure the domains that are
simultaneously competing for the same resource will share that resource in proportion to their
reservations, independent of their previous usage of that resource. A fair scheduling policy does
not penalize a domain that utilized an idle resource beyond its reservation when other domains
become busy on that resource. The definition of fairness is based on another idealized service
model call processor sharing (ideal processor sharing cannot be implemented in practice). Under
processor sharing each domain receives a service proportional to its fraction on a resource. A
scheduling policy is thus defined as “fair” if there exists a constant F such that for any time
interval |T, t| during which a pair of domains Di and Dj, both continuously require the resource, we
have | si (T,t)/ai – sj (T,t)/aj | < F. Admission control makes sure that the sum of the service
fractions of all domains does not exceed certain bounded limits.
Admission control is not
required for fairness but is necessary for delay and cumulative service guarantees.
 Cumulative Service Guarantee
The cumulative service guarantee parameter compares the performance of the real service time
to the idealized model (virtual service time). In order for a system to provide a performance as
6
good as the one in the idealized model, the total real time si (T,t) + wi(T,t) spent by a domain at
the resource in interval (T, t) to receive vi(T, t) virtual service time should be less than or equal to
vi(T,t). A scheduling policy provides a cumulative service guarantee if there exists a constant K
such that for all domains Dj and T< t there exists vj (T,t ) > wj(T,t) + sj(T,t) – K.
 Delay
Delay guarantee can be defined as the case when at any given time there is only one process
within a reservation domain. When there are multiple concurrent processes within a domain, the
delay experienced depends on how the reservation domain schedules its phases. A scheduling
policy provides delay if for a phase of any domain, the real waiting time plus the service time to
complete the phase takes at most a constant amount more than d/aj where d is the duration of the
phase.
2.1.5 Move-to-Rear List Scheduling (MTR-LS)
The algorithm that Eclipse utilizes for scheduling provides all three quality of service parameters:
bounded delay, cumulative guarantee, and fairness. At the core of the MTR-LS policy is an
ordered list L of pairs (i, left) where i is the index of a reservation domain and left is the size of the
quantum which is the maximum amount of service time reservation domain D i can receive without
being interrupted. There can be multiple occurrences of domain D i on L, pairs appearing at
different positions in the list L that have the same first coordinate i. The pairs (i, left) are called
tokens.
MTR-LS performs several routines:
2.2

Decision epoch routine is called at (1) the arrival of a new domain, (2) the departure of a
domain, (3) expiration of the current domain, (4) the completion of the phase of the
current running process (e.g. process blocks), or the end of the current pre-emption
interval. Therefore, a currently running process may be pre-empted only at the end of
the current pre-emption interval or at the end of the current quantum.

Domain update routine runs when every decision epoch routine is called in order to
update the token of the currently running domain. This routine can either (1) split the
current token into two leaving one token in the current place and appending the other to
the end of L or (2) move the token entirely to the end of L depending on the remaining
quantum in the token.

Run a domain routine selects the next domain to run on the resource. A counter records
the elapsed time to the next decision epoch.

Combine elements routine combines neighboring tokens belonging to the same domain
and is called whenever the list is changed. This routine examines the list when a
change (addition or removal of token) has occurred.
Nemesis
Nemesis provides quality of service via the following techniques: QoS Manager, QoS
parameters used in Run Time Resource Allocation, Accounting and Policing.
2.2.1 Quality of Service Manager
Figure 2 shows how Nemesis’ operating system is constructed to provide quality of service for its
applications. The diagram shows the application as either a client or a server. The module
responsible for QoS is the QoS manager. The QoS manager’s main function is to come to an
agreement with processes about the quality of service that will be delivered to them. An
application presents to the quality of service manager a description of its requirements and the
manager converts it to a set of parameters called quality of service parameters. The manager
7
then decides whether or not it can accommodate this request. If the quality of service requested
cannot be provided, the application is informed and the user may be informed directly by the
quality of service manager or by the application. If the level of quality can be provided then the
resources required to provide it are noted and the application is informed of their availability. A
contract is thus formed between the application and the system. The manager communicates the
applications QoS parameters to the run-time resource allocator (RTRA) that uses them in
conjunction with some knowledge of the current time to allocate the resources to the application.
Some means of accounting and policing are needed so that when resources are limited, an
application cannot use more than has been put aside for it.
QoS Description
Contract
QoS Manager
Application
Resource
Allocation
Parameters
Run Time Resource Allocation
Accounting
Time
CPU
/
Memory
Policing
….
I/O
Figure 2. QoS Management
2.2.2 Run Time Resource Allocation
The run time resource allocator (RTRA) assigns the available resources among those
applications that need to use them. It does this using information in the form of QoS parameters
supplied by the QoS manager. The system dispatcher in the case of the processor resource
performs run time allocation. The dispatcher sees the application resource requests as a series
of tasks that are placed in individual queues to wait until the processor can be allocated to them.
When a request is serviced, the dispatcher selects a task from the head of one the queues then
allocates the processor to it for a certain interval. The queue it chooses from may be assigned by
the QoS manager or based on some service algorithm. The service algorithm and appointed
service times need to be chosen so that contracts between the QoS manager and the application
are met.
2.2.3 Accounting
Current kernals already account for resources used by an application when a running total of the
time spent by an application in both user and supervisor mode is calculated. The cost of
resources is charged to the accounting structure that is associated with the currently executing
user mode protection domain. However, with a number of clients and servers running on top of a
microkernal, accounting for resource usage can become complicated because the single client
may need to interact with a number of servers during execution. In order to solve this problem
two approaches are possible: use of credits or a request to connect to a server with a particular
QoS.

Credits: An application can be allocated credits at a rate determined by its process
block. A number of credits are nominated whenever it interacts with a server. The
credits are then withdrawn from the applications account and put into the servers
8

account so that the server may do work for each of its clients on the basis of credits it
receives from them. This approach separates the accounting from the process’s
address space but has some disadvantages:
o It is possible for a server to use resources given to it by one client for other
purposes.
o It requires knowledge of whether a particular server is on the same system as the
client.
o It increases the overhead required for client-server interaction.
Connection to a QoS server: With connection to a server with a particular QoS, the
client and server perform negotiation and reservation actions. After the QoS is
supplied, the server knows the resources that will be required to service any requests
that arrive on that specific path. This does not add overhead of client-server
interactions even when clients and servers are on different machines. There are some
disadvantages to this as well:
o The server has to perform some of the QoS management functions such as
policing.
o Poorly constructed servers may state a level of service that cannot be provided.
2.2.4 Policing
Policing is required at a low level and at a high level in the system. At the low level policing is
needed to ensure that an application does not exceed its allocation and start consuming
resources reserved for other applications. A dispatcher can ensure that processor time is
precisely monitored. At the higher level, a method of ensuring that the writer of the application
does not request excessive resources to guarantee that applications perform satisfactorily.
Meager utilization will result and the unknowing user will prefer programs that behave more
conservatively with system resources.
2.3
Real-Time Mach
Real-time Mach uses the Q-RAM (QoS-based Resource Allocation Model) and a combination of
a processor reserve and a QoS server to provide dynamic quality of service support and predict
end-to-end delays in distributed applications.
2.3.1
Processor Reserves
The RT-Mach microkernal supports a processor reserve concept that allows threads to specify
their CPU resource requirements in terms of their timing constraints. The required CPU demand
is thus made available upon admission of the processor reserve by the kernal. In order to
support the processor reserve, the kernal performs the following tasks:






Admission control (CPU usage per some time interval)
Scheduling application threads to satisfy timing constraints
Allowing multiple threads to be bound by the same reserve
Binds applications without reserves to a default reserve which is scheduled only where
there are no other threads bound reserves ready to run
Ensures that only the reserve specification is guaranteed and beyond the stated usage
level, suspends or executes the demanding application threads at lower priority
Monitors the execution time of threads to enforce reserves while providing a basis for
measuring amount of time spent by threads, overhead and CPU idleness
2.3.2 Dynamic QoS Server
The objective of the dynamic QoS server is to provide interaction between the application and the
system layer whereby the application can specify its requirements to the system layer while the
system layer provides to the application accurate and dynamic feedback on the state of the
applications resources both individually and with respect to other applications.
9
The architecture of the QoS Server is shown in Figure 3. The QoS Server interacts with the
processor reservation in the Real-Time Mach and the QoS interfaces both of the clients.
The QoS server is based on the following concepts:

QoS attributes are used by application threads to specify their acceptable quality levels.
The kernal specifies a fixed computation time and a fixed period. The attributes include
minimum, maximum and most-desired levels of the computation time as well as
minimum, maximum and most-desired levels of the computation period. Thus, if an
application chooses a range of acceptable computation times or periods, the server is
free to pick a valid time/period within this range. The server attempts to give each
application the maximum quality value in this range, but it will not go below the
minimum required value when an application is admitted.

Quality adjustment policies are used by the server if the quality guarantee given to an
application needs to be upgraded or downgraded. The policies describe how the
application wants to be handled in case resources need to be altered. The policies
include a quality adjustment priority that determines the quality and which application
the server will upgrade or downgrade.

Admission control adjustment policies admits as many new application requests as
possible without violating the needs of the currently registered applications.

Overrun control policies attempt to satisfy the requirements of registered applications
whose current CPU demands exceed their actual allocation. The QoS server,
therefore, looks to those applications not using their current resource allocation.
Client
QoS
Interface
Client
QoS
Interface
QoS Server
Display
Admission
Control
Dynamic
Quality Control
Client Quality
Attribute Database
Processor Reservation
Real- Time Mach
Figure 3. QoS Server Architecture
2.3.3 Q-RAM (QoS-based Resource Allocation Model)
The goal of Q-RAM development is to fulfill simultaneous requirements of multiple applications
along multiple QoS dimensions (e.g. timeliness, data quality, reliable packet delivery) while
allowing applications access to multiple resources (e.g CPU, disk bandwidth, memory)
simultaneously.
10
Q-RAM was designed for systems where each application, each with its own set of resource
requirements along multiple QoS dimensions is competing for identical resources. Q-RAM uses a
dynamic and adaptive framework where each application requires a certain minimum resource
allocation to perform adequately. When larger resources are allocated, an application’s
performance improves. The improvement is measured via a utility function. With Q-RAM
specifications, a resource allocation decision will be made for each application such that an
overall system level objective (utility) is maximized.
The model consists of the following characteristics, definitions and assumptions that apply to the
model:
Characteristics:
 The system consists of n applications (T 1, T2,…Tn) where n > 1 and m resources (R1,
R2….Rm) where m > 1. Each Resource Rj has a finite capacity and can be shared.
CPU and network bandwidth for example would be time-shared resources while
memory would be spatially shared resources.
 The portion of resource Rj allocated to application Ti is denoted as Ri,j.
n

The constraint holds:
R
 Rj .
i, j
i 1
Definitions:
 Application Utility (Ui) of an application Ti is defined to be the value that is accrued by the
system when Ti is allocated Ri = (Ri,1, Ri,j…., Ri,m). Thus Ui = Ui(Ri). Ui is referred to as
the utility function of Ti. This function defines a boundary along which the application
can operate based on the resources allocated to it.
 Each application Ti has a relative importance specified by a weight wi where 1 < i < n.
The total system utility U (R1, …Rn) is defined to be the sum of the weighted application
n
utilities. U(R1,…,Rn) =
 w U (R )
i
i 1



i
i
Each application Ti needs to satisfy requirements along d QoS dimensions (Q 1, Q2, ,,,,
Qd), where d > 1.
The dimensional resource utility Ui,k = Ui,k (Ri) of an application Ti is defined to be the
value that is accrued by the system when Ti is allocated Ri for use on QoS dimension
Qk, 1 < k < d.
An application has minimal resource requirements on QoS dimension Qk defined by:
min k
min k
min k
k
Rimin k  ( Rimin
 0,0  j  m.
,1 , Ri , 2 ,...Ri ,m ) where Ri , j

An application Ti is feasible if it is allocated a minimum set of resources for every QoS
dimension. The minimum requirements are defined by:
min
min
Rimin  ( Rimin
,1 , Ri , 2 ,..., Ri , m )
d
min
min
where Ri , j   Ri , j k ,1  j  m.
k 1
Assumptions:
 Applications are independent of one another
 Available system resources are sufficient to meet the minimal resource requirements of
each application on all QoS dimensions.
 Utility functions are non-decreasing and in some cases function concavity and two
continuous derivatives will be assumed as well.
The Q-RAM model takes the characteristics, definitions and assumptions and makes resource
allocations to each application such that the total system utility is maximized with the constraint
that every application is feasible with respect to each QoS dimension.
11
3.0 Conclusions and Summary
All three systems Eclipse, Nemesis and RT Mach, use different techniques when implementing
quality of service. However, there are important distinctions and similarities in the methodologies
used to implement quality of service. One important distinction is the manner in which quality of
service was added to the systems. Eclipse appears to add the mechanisms to support QoS in
the existing operating system while Nemesis developed a separate module (QoS manager) and
provided links to integrate the module into the system. The disadvantage of the Eclipse method
of implementation is that in adding the mechanisms within the existing operating system, there is
the possibility of having to alter the quality of service mechanisms in order to fit them into the
system, thereby drifting from the exact quality of service requirements or objectives. Once
implemented in this manner, there is also risk of inaccurately measuring the performance. In
addition, the mechanisms that are added are at the lower levels of the operating system and are
at risk of propagating effects through larger portions of the system. RT Mach’s approach is more
similar to Nemesis in that it implemented the majority of its changes in the QoS server, a separate
module, and integrated it to the RT Mach operating system with links limited to the processor
reserves area of the operating system.
Using a quality of service server was a main feature of the Real-Time Mach, but was also used in
implementation of accounting in Nemesis. Thus, a QoS server can be used in implementing
quality of service and it is up to the architect of the system to evaluate the benefits of its use and
determine in what capacity it is used.
All three systems use a mathematical model in determining resource allocation to the
applications. Eclipse’s scheduling policy uses a cumulative service guarantee, fairness and delay
quality of service parameters and compares the virtual service time to real service time in order to
determine resource allocation. Real-Time Mach, on the other hand, uses the Q-RAM model
where it inputs its quality of service parameters to generate utility functions that are then
optimized to achieve a certain level of performance. Nemesis utilizes the RTRA to assign the
available resources among applications using QoS parameters supplied by the QoS manager. In
the case of the CPU, a dispatcher is used.
4.0 Other Implementations of Quality of Service
There are several other experimental operating systems that have attempted to use new
techniques in addition to methods similar to those used in Eclipse, Nemesis, or Real-Time Mach
in order to guarantee quality of service:






Sumo (Lancaster University)
Synthesis (Columbia University)
Synthetix (Oregon Graduate Institute)
Vino (Harvard University)
Tornado (University of Toronto)
Scout (University of Arizona)
12
5.0 References
P. Barham, “A Fresh Approach to File System Quality of Service”. Proceedings of IEEE. June,
1999
J. Blanquer, J. Bruno, E. Gabber, M. Mcshea, B. Özden, and A. Silberschatz, "Resource
Management for QoS Eclipse/BSD”. Proceedings of the FreeBSD 1999 Conference,
Berkeley, California, October 1999.
J. Bruno, J. Brustoloni, E. Gabber, B. Özden, and A. Silberschatz, "Retrofitting Quality of Service
into a Time-Sharing Operating System”, Proceedings of the USENIX 1999 Annual Technical
Conference, Monterey, California, June 1999.
J. Bruno, J. Brustoloni, E. Gabber, M. McShea, B. Özden, and A. Silberschatz, "Disk Scheduling
with Quality of Service Guarantees". ICMCS99, June 1999.
J. Bruno, E. Gabber, B. Özden, and A. Silberschatz, "The Eclipse Operating System: Providing
Quality of Service via Reservation Domains”. Proceedings of the USENIX 1998 Annual
Technical Conference, New Orleans, Louisiana", June 1998.
J. Bruno, E. Gabber, B. Özden, and A. Silberschatz, "Move-To-Rear List Scheduling: a New
Scheduling Algorithm for Providing QoS Guarantees”. Proceedings of ACM Multimedia
Seattle, Washington", November 1997.
E. Hyden. “Operating System Support for Quality of Service”. Dissertation for degree of Doctor
Of Philosophy. February, 1994, Chapters 3 and 4.
R. Pike, D. Presotto, S. Dorward, B. Flandrena, K. Thompson, H. Trickey, P. Winterbottom.
“Plan 9 from Bell Labs”. Bell Laboratories, Murray Hill: New Jersey . Computing Systems,
Vol 8 #3, Summer 1995, pp. 221-254.
R. Rajkumar, C. Lee, J. Lehoczky and D. Siewiorek, "Practical Solutions for QoS-based
Resources Allocation Problems" In Proceedings of the IEEE Real-Time Systems
Symposium December,1998.
R. Rajkumar, C. Lee, J. Lehoczky and D. Siewiorek. "A Resource Allocation Model for QoS
Management" In Proceedings of the IEEE Real-Time Systems Symposium December, 1997.
R. Rajkumar, C. Lee, and C. Mercer "Experiences with Processor Reservation and
Dynamic QOS in Real-Time Mach" In Proceedings of Multimedia Japan March 1996
www.cs.arizona.edu/people/bridges/os/qos.html
www.cl.cam.ac.uk/Research/SRG/netos/
www.freebsd.org
13
14