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
  • Real-time 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
    1. A priori knowledge of
  • Applications to be executed
  • Application resource needs (usually based on worst-case assumptions)
    • 2. 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

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