1. IIT Comparative Operating Systems December 2001 CS550 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

2. IIT Comparative Operating Systems December 2001 CS550 Agenda  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

3. IIT Comparative Operating Systems December 2001 CS550 Motivation for Quality of Service  An 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  A 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

4. IIT Comparative Operating Systems December 2001 CS550 Operating System Overview  Eclipse/BSD (Berkeley Software Distribution)  Nemesis  Real Time (RT) Mach

5. IIT Comparative Operating Systems December 2001 CS550 Overview of Eclipse/BSD  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)  Administrators 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.

6. IIT Comparative Operating Systems December 2001 CS550 Overview of Nemesis  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 Alpha workstations, StrongARM SA-110 based network computers

7. IIT Comparative Operating Systems December 2001 CS550 Overview of Real-Time Mach  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 Alpha and IBM-s OS/2 for the RS6000 based machines

8. IIT Comparative Operating Systems December 2001 CS550 Techniques for QoS Implementation  Eclipse/BSD  Reservations, Tagging, Reservation Domains, Cumulative Service Guarantee, Move-to-Rear List Scheduling (MTR-LS)  Nemesis  Quality of Service Manager, Run Time Resource Allocation (RTRA), Accounting, Policing  Real-Time Mach  Processor Reserves, Dynamic QoS Server, QoS-based Resource Allocation Model (Q- RAM )

9. IIT Comparative Operating Systems December 2001 CS550 Eclipse/BSD – QoS Techniques  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

10. IIT Comparative Operating Systems December 2001 CS550 Eclipse/BSD – QoS Techniques  Reservation Domain  Offers access and admissions to the /reserv file system  Allows control over system resources among applications in order to achieve a desired performance level  Assigns a certain fraction of each resource: a domain may contain 25% CPU, 50% disk I/O, 25% main memory  Move-to-Rear List Scheduling Algorithm  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

11. IIT Comparative Operating Systems December 2001 CS550 Nemesis - QoS Techniques  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 (RTRA)  Assigns 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

12. IIT Comparative Operating Systems December 2001 CS550 Nemesis - QoS Techniques

13. IIT Comparative Operating Systems December 2001 CS550 Nemesis - QoS Techniques  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  Accounting  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

14. IIT Comparative Operating Systems December 2001 CS550 Real-Time Mach QoS Techniques  Processor Reserves  Allow 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  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

15. IIT Comparative Operating Systems December 2001 CS550 Real-Time Mach QoS Techniques

16. IIT Comparative Operating Systems December 2001 CS550 Real-Time Mach QoS Techniques  QoS Based Resource Allocation Model (Q-RAM)  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

17. IIT Comparative Operating Systems December 2001 CS550 Conclusion  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  Real-Time Mach uses the Q-RAM model where it inputs its quality of service parameters to generate utility functions that are then optimized  Nemesis utilizes the RTRA to assign the available resources among applications using QoS parameters supplied by the QoS manager

18. IIT Comparative Operating Systems December 2001 CS550 Conclusion  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

19. IIT Comparative Operating Systems December 2001 CS550 Operating Systems with QoS Capability  Sumo (Lancaster University)  Synthesis (Columbia University)  Synthetix (Oregon Graduate Institute)  Vino (Harvard University)  Tornado (University of Toronto)  Scout (University of Arizona)

20. IIT Comparative Operating Systems December 2001 CS550 Representative List of References  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, 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.  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. "A Resource Allocation Model for QoS Management" In Proceedings of the IEEE Real-Time Systems Symposium December, 1997.  See Report for remaining references