||

p




 

  
 
! 
 





|  




 

R
 
|| "
p



£ Motivation for Quality of Service Implementation

£ Overview of Operating Systems
£ Eclipse/BSD
£ Nemesis
£ Real Time Mach
£ Techniques for Implementing Quality of Service
£ Eclipse/BSD
£ Nemesis
£ Real Time Mach
£ Conclusion
£ References



 

R
 
||  
  
p



£ un increasing need to run multiple server applications

(audio and video media servers, web servers and host
services) for organizations and individuals on the same
platform

£ u need for control over provisioning of system

resources among applications to achieve desired levels
of predictable performance

£ Quality of service guarantees with respect to packet

delay and bandwidth are not extended directly to the
application via the operating system and thus add little
value



 

R
 
|| ! !#
p



£ x
!"#"
$

%
 &

£ '



£ 
 
# & (



 

R
 
|| !# $% &
p



£ Evolved from the Plan 9 operating system developed by

Bell Laboratories in New Jersey starting in the late 1980·s
in response to trends in the computing industry at that
time:

£ Networks of smaller, more personal machines were

preferred over large centralized time-shared computers
(typically UNIX workstations)
£ udministrators grew weary of overloaded, routine time-
sharing systems and wished to move to small, self-
maintained systems

£ Referred to as Eclipse/BSD based off of FreeBSD (Berkeley

Software Distribution) version 3.4.



 

R
 
|| !# 
p



£ Resulted from work completed for the Pegasus and

Pegasus II projects and the following partnerships:

£ 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.

£ Runs on a large number of platforms including Intel

486, Pentium, PPro, DEC ulpha workstations,
StronguRM Su-110 based network computers



 

R
 
|| !#  
p



£ Research began in 1985 and resulted in a flagship

product developed by the Real-Time and Multimedia
Laboratory in partnership with the Department of
Computer Science at Carnegie Mellon University.

£ Incorporated into a number of commercial operating

systems including DEC·s OSF/1 for the DEC ulpha and
IBM-s OS/2 for the RS6000 based machines



 

R
 
|| 
  
p



£ Eclipse/BSD
£ Reservations, Tagging, Reservation Domains,
Cumulative Service Guarantee, Move-to-Rear List
Scheduling (MTR-LS)

£ Nemesis
£ Quality of Service Manager, Run Time Resource
ullocation (RTRu), uccounting, Policing

£ Real-Time Mach
£ Processor Reserves, Dynamic QoS Server, QoS-
based Resource ullocation Model (Q-RuM )



 

R
 
|| $% &'  

p



£ Reservations
£ /reserv (reservation) file system through which the operating
system can access, use and reconfigure the system resource
schedulers
£ Each resource contains a reservation directory (Example for
CPU with multiple resources: /reserv/CPU/r1, /reserv/CPU/r2,
etc. )

£ Quality of Service Parameters: Delay, Fairness, and Cumulative

Service Guarantee*
£ Used to determine resource allocation to the applications
£ Obtains quality of service parameters and compares the virtual
service time to real service time



 

R
 
|| $% &'  

p



£ Reservation Domain
£ Offers access and admissions to the /reserv file system
£ ullows control over system resources among applications in
order to achieve a desired performance level
£ ussigns a certain fraction of each resource: a domain may
contain 25% CPU, 50% disk I/O, 25% main memory

£ Move-to-Rear List Scheduling ulgorithm

£ Provides all three quality of service parameters: bounded delay,
cumulative guarantee, and fairness
£ Contains an ordered list of pairs that indexes the reservation
domain and specifies the size of the quantum or the maximum
amount of service time the reservation domain can receive
without being interrupted



 

R
 
||   

p



£ Quality of Service Manager

£ Comes to agreement with processes about the quality of service that
will be delivered to them
£ Receives a description of requirements from the application and
converts it to a set of QoS parameters
£ Decides whether or not it can accommodate the request
£ Informs the application directly if level of service cannot be met
(user is informed by QoS manager or application)
£ Informs application of resource availability if service level can be
met
£ Run time resource allocator (RTRu)
£ ussigns the available resources among those applications that need to
use them by using QoS parameters supplied by the QoS manager
£ System dispatcher performs run time allocation in the case of the
processor resource



 

R
 
||   

p



Ô
Ô   Ô 
 
 Ô
Ô
Ô   
Ô
  Ô

 Ô
u   


Ô
   Ô


  Ô u 

 Ô
Ô
ÔÔÔÔÔÔÔÔÔ  Ô
 Ô    Ôu 

Ô

u  
ÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔ  

Ô

Ô

 ÔÔÔÔÔ   ÔÔÔÔÔ  
ÔÔÔÔÔÔÔ ÔÔÔÔÔÔÔÔÔÔÔÔÔ Ô

Ô 
   
     
  
Ô
Ô



 

R
 
||   

p



£ Policing
£ Ensures that an application does not exceed its allocation and start
consuming resources reserved for other applications (dispatcher
monitors processor time)
£ Ensures that the writer of the application does not request
excessive resources to guarantee that applications perform
satisfactorily

£ uccounting
£ Kernals already account for resources used by an application
£ Cost of resources is charged to the accounting structure that is
associated with the currently executing user mode protection
domain (complicated because the single client may need to interact
with a number of servers during execution)
£ Credits or connection to a QoS server can be used to resolve this
issue



 

R
 
||   

p



£ Processor Reserves
£ ullow threads to specify their CPU resource requirements in
terms of their timing constraints
£ CPU demand is thus made available upon admission of the
processor reserve by the kernal

£ Dynamic QoS Server

£ Provides interaction between the application and the system
layer
£ upplication 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



 

R
 
||   

p



ÔÔÔ
   
ÔÔÔÔÔÔ ÔÔÔÔÔÔÔÔÔ
 
Ô ÔÔ  
Ô
Ô Ô

ÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔ   
ÔÔÔÔÔÔÔÔÔ
ÔÔ ÔÔÔÔÔ


ÔÔÔ
ÔÔÔÔÔÔ
ÔÔu

ÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔ


ÔÔÔÔÔÔ
 ÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔ


Ô ÔÔÔ
Ô
Ô

Ô


ÔÔ
u
Ô


ÔÔ
Ô

   Ô 

ÔÔ

ÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔÔ
 



Ô
  
  
 
 

Ô



 

R
 
||   

p



£ QoS Based Resource ullocation Model (Q-RuM)

£ Fulfills 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

£ 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



 

R
 
|| p

p



£ ull 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
£ Real-Time Mach uses the Q-RuM model where it inputs its
quality of service parameters to generate utility functions that
are then optimized
£ Nemesis utilizes the RTRu to assign the available resources
among applications using QoS parameters supplied by the
QoS manager



 

R
 
|| p

p



£ Operating Systems used different methods of implementing QoS

£ Eclipse appears to add the mechanisms to support QoS in the
existing operating system
£ Nemesis developed a separate module (QoS manager) and provided
links to integrate the module into the system
£ RT Mach implemented the majority of its changes in the QoS server, a
separate module, and integrated it to the operating system with links
limited to processor reserves area of the operating system

£ Disadvantages of integrating quality of service in an existing system

£ Possible drift from exact quality of service requirements or objectives
because altering was needed to fit the quality of service mechanisms
into the system
£ Risk of inaccurately measuring the performance
£ Risk of propagating effects through larger portions of the system
because the mechanisms added are at the lower levels of the
operating system



 

R
 
|| ! # p(
p



£ Sumo (Lancaster University)

£ Synthesis (Columbia University)
£ Synthetix (Oregon Graduate Institute)
£ Vino (Harvard University)
£ Tornado (University of Toronto)
£ Scout (University of urizona)



 

R
 
|| )  
p



£ J. Blanquer, J. Bruno, E. Gabber, M. Mcshea, B. Özden, and u.

Silberschatz, "Resource Management for QoS Eclipse/BSDµ
Proceedings of the FreeBSD 1999 Conference, Berkeley, California,
October 1999.
£ J. Bruno, E. Gabber, B. Özden, and u. Silberschatz, "The Eclipse
Operating System: Providing Quality of Service via
Reservation Domainsµ. Proceedings of the USENIX 1998
unnual Technical Conference, New Orleans, Louisiana", June
1998.
£ E. Hyden. ´Operating System Support for Quality of Serviceµ.
Dissertation for degree of Doctor Of Philosophy. February,
1994, Chapters 3 and 4.
£ R. Rajkumar, C. Lee, J. Lehoczky and D. Siewiorek. "u Resource ullocation
Model for QoS Management" In Proceedings of the IEEE Real-Time Systems
Symposium December, 1997.
£ See Report for remaining references



 

R