Overview - General purpose processing (1 week) - Hard real-time systems (2-3 weeks) - Soft real-time systems (4 weeks) - Quality of Service (2 weeks) - Projects ----- General-Purpose Systems Principles - Availability - Utilization - Fairness - Reliability/graceful degradation - Generality/Unspecialized - Speed - Safety/security - Simplicity Resources - CPU - Memory - Files - Network - The kernel - System services - Devices API 1. Applications request CPU implicitly by being schedulable, i.e., by running. 2. Applications request some resources indirectly by requesting service - Network - by sending data (don't know how many packets) - Files - by writing to the file (don't know how many blocks) 3. Applications request other resources directly at the time that they need them - Memory - by asking for a specific number of bytes or by allocating an object - In general, the application either gets an error message indicating that the request is unservicable or blocks until the request has been satisfied (or crashes the system) Approaches - Flexible scheduling algorithms - First-come-first-serve - Queues - Virtual memory - High-level interfaces Examples - Unix - Windows - MacOS Applications - Word processing - Spreadsheets - Browsers Plusses - Good for general purpose processing - Very flexible - can do almost any kind of processing, but perhaps not very well - Good for prototyping Issues - Excess overhead - generality leads to inefficiencies - Poor performance - doesn't do any one thing particularly well - Huge - it's expensive to do everything - Hard to modify - so many interconnected pieces - Error-prone - there are always problem with very large systems - No guarantees - everything is best effort ----- Lots of specialized systems address different aspects of these - Database systems - Cash machines - Airline reservation systems - Embedded systems - etc. ----- Hard Real-Time Systems Principles - Guaranteed performance - Reliability - Efficiency - Best effort principles, as much as possible Resources - Only those that can provide guaranteed service times - no virtual memory - no internet - Often constrained further by data rate API - A priori knowledge of - Applications to be executed - Application resource needs (usually based on worst-case assumptions) - This information may be implicit or explicit - Implicit - System designer knows this information and designs the system appropriately - Explicit - Applications specify the information Approaches - Specialization - Applications specify deadlines - Predictable scheduling algorithms - Earliest deadline first - Rate monotonic - Least laxity first - ... - Predictable and carefully measured applications - Must be able to specify worst-case execution time - Job admission control - Detailed a priori knowledge of applications, data, etc. - Low level interfaces for high degree of control - Predictable system services - Limited use of unpredictable services (e.g., internet) Examples - VxWorks - RTOS - pSOS - Spring - Real-time Linux (sort of) - NT & Solaris (in a very limited fashion) - ... Applications - Flight control - Medical devices - Robotics - Automobiles - ... Plusses - Guaranteed performance - Predictable - Less error-prone (mostly because they don't do as much) - More secure (for the same reason) - Usually faster (ditto) Issues: - Job admission - Priority inversion - Inflexibility - Often engineered for a single job - Don't do anything else, well or otherwise - Need a priori information - Worst-case assumptions lead to very poor resource utilization - Can't handle mix of real-time and non-real-time applications - Enforce absolute guarantees - can't provide anything in between ----- Soft real-time (4 weeks) Principles - All principles from both general purpose and hard real-time except - Failure to meet a deadline is considered neither application nor system failure - It's just considered less "good" - What that means is poorly defined and varies from system to system Resources - Primarily CPU and network - Everything else, to a lesser degree API 1. Applications try to run and unimportant ones are dumped (collaborative load shedding) or simply don't run non-critical parts (SPRING) 2. Applications try to run and get a proportional share of the resources (SMART) 3. Applications explicitly reserve the resources they need (RT-Mach w/Reserves, Rialto) on a FCFS basis 4. Applications specify a range of acceptable resource allocations, and the system dynamically determines how much they get (MMOSS) 5. Applications specify cost-benefit functions and the system determines how much resources they should get, and when, based on this function (Jensen, CMU, DQM). - In general, the application may or may not get the resources it needs - It may or may not be informed when it has missed a deadline - The application may or may not negotiate for the resources Approaches - Flexible scheduling algorithms - First-come-first-serve reservations - Renegotiation - Cooperation vs. enforcement - Low-level system, high-level system, middleware, application - All or nothing vs. partial allocations - Static vs. dynamic allocation schemes - Job admission or not - Incorporate real-time and non-real-time (spectrum?) - ... Examples - Mach, Rialto (MS), lots of other experimental systems - RealAudio/Video (application solution) Applications - Desktop audio and video - Virtual reality - Internet telephony - Any non-critical real-time systems - Any system with timeliness concerns Plusses - Allows for some sort of guarantees in time-sensitive applications - Allows for less-than-worst-case resource allocations ********** Issues - Everything - How soft are the guarantees - What kind of guarantees are offered - How to mix in non-real-time apps - How to have a spectrum of softness - API and development overhead (hard real-time requires much more knowledgeable developers) - How to do it - How to measure performance - What to do when there are too many applications - What constitutes adequate perfomance - How do you decide how to parcel out the resources - What happens when a deadline is missed - ... ----- - Quality of Service (2-3 weeks) - Principles and issues - Systems - Kravetz, Abdelzaher, ...