Scheduling Aperiodic Tasks Background Scheduling Treat aperiodic - PDF document

Scheduling Aperiodic Tasks Background Scheduling • Treat aperiodic tasks as lowest-priority tasks • Hybrid task set: periodic tasks + aperiodic tasks • Advantages • Problem: Arrival time is unknown • Sporadic task with a hard deadline • Simple • Aperiodic tasks has no impact on the • Inter-arrival time must be lower bounded schedulability of periodic tasks • Schedulability analysis: treated as a periodic task with period = minimum inter-arrival time • Disadvantage • Aperiodic task with a soft deadline • Aperiodic tasks have very long response times • Possibly unbounded inter-arrival time when the utilization of periodic tasks is high • Goals: • Acceptable only if • maintain hard guarantees on periodic tasks • System is not busy • reduce response time of aperiodic tasks • Aperiodic tasks can tolerate long delays Chenyang Lu CSE 467S 1 Chenyang Lu CSE 467S 2 Polling Server Schedulability • Polling server (PS): a periodic task used to • The aperiodic requests have the same impact serve aperiodic requests on periodic tasks as a periodic task. • Period: p s • n tasks with m PS’: U p + U s ≤ U b (n+m) • Capacity: c s • Can have multiple PS’ (with different periods) • Rules for different aperiodic requests • Released periodically with period p s • Serves any pending aperiodic requests • Disadvantage: If an aperiodic request • Suspends itself if “misses” the execution of PS, it has to wait • it has used up its capacity, or till the next period � long response time. • no aperiodic request is pending • Server capacity is replenished to c s in the next period Chenyang Lu CSE 467S 3 Chenyang Lu CSE 467S 4 Utilization Bound with DS Deferrable Server (DS) ⎡ ⎤ 1 n / ⎛ ⎞ U + 2 • Unlike PS, DS preserves unused capacity until the end • Under RMS ⎢ ⎜ ⎟ ⎥ s U U n 1 = + ⎜ ⎟ − b s ⎢ ⎥ of the current period ⎝ ⎠ 2 U + 1 ⎣ ⎦ s • Better response to aperiodic requests • However, DS’ impact on periodic tasks is different ⎛ ⎞ U 2 + • As n � ∞ : from an periodic task ⎜ ⎟ s U = U + ln ⎜ ⎟ b s ⎝ 2 U 1 ⎠ + s • When U s = 0.186, min U b = 0.652 ⎛ ⎞ U + 2 • System is schedulable if ⎜ ⎟ s U ≤ ln ⎜ ⎟ p ⎝ ⎠ 2 U + 1 s Chenyang Lu CSE 467S 5 Chenyang Lu CSE 467S 6

Pointers Real-Time Operating Systems • Class hand-out • Proprietary kernels • Rate Monotonic • Real-time extensions to general-purpose OS • A Practitioner's Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Klein et. al. • EDF • Deadline Scheduling for Real-Time Systems: EDF and Related Algorithms, Stankovic et. al. • General • Hard Real-Time Computing Systems, G. Buttazzo. • Real-Time Systems, Jane Liu. Chenyang Lu CSE 467S 7 Chenyang Lu CSE 467S 8 Proprietary Kernels Features for Efficiency • Commonly used for small embedded systems • Small • Homegrown kernels • Minimal set of functionality • Highly specialized for specific applications • Fast context switch • e.g., nuclear power plant • Fast and time bounded response to interrupts • Less common • Fixed or variable partitions of memory • Commercial RTOS • May not support paging or virtual memory • Often support locking code and data in memory • Sequential file that can accumulate data at fast rate • May be memory-based Chenyang Lu CSE 467S 9 Chenyang Lu CSE 467S 10 Code Size Features for Real-Time Name Code Size Target CPU • Priority-based preemptive scheduling pOSEK 2K Microcontrollers • At least 32 priority levels, commonly 128-256 priority levels pSOSystem PII->ARM Thumb • Priority inheritance/ceiling protocol VxWorks 286K Pentium -> Strong ARM • Usually does not directly support EDF QNX Nutrino >100K Pentium II -> NEC • System calls QNX RealTime 100K Pentium II -> SH4 OS-9 Pentium -> SH4 • Bounded execution times Chorus OS 10K Pentium -> Strong ARM • Short non-preemptable code ARIEL 19K SH2, ARM Thumb • High-resolution system clock Creem 560 bytes ATMEL 8051 • Resolution down to nanoseconds • But it takes about a microsecond to process a timer • QNX context switch = 2400 cycles on x86 interrupt • pOSEK context switch > 40 µs • Creem -> no preemption Chenyang Lu CSE 467S 11 Chenyang Lu CSE 467S 12

Other important features Development Environment • Conformance to Standards • Self-hosted system: applications are developed on the target platform • Real-Time POSIX API • OS must support compilers, debuggers, • Modularity and configurability performance profilers • Small kernel • Large memory demand • Pluggable modules • E.g., LynxOS • Networking support • Cross-platform development • TCP/IP • E.g., Tornado environment for VxWorks OS Chenyang Lu CSE 467S 13 Chenyang Lu CSE 467S 14 Example: VRTX Example: VxWorks • Two versions • Not a UNIX system, but provides most • VRTXsa POSIX functions • RT-POSIX compliant • System calls with timeout • Full real-time support • E.g., Semaphore operations. • VRTXmc • Optimized for power and footprint • Used by NASA • First RTOS certified by FAA • 100% code coverage in testing • e.g., Used by Boeing MD-11 Chenyang Lu CSE 467S 15 Chenyang Lu CSE 467S 16 Real-Time Extensions to General- Categories of RT-Linux Purpose OS • Compliant kernels • Generally slower and less predictable than • modified native RTOS proprietary RTOS • Linux binaries can run without modifications • Much greater functionality and development • E.g., LynxOS support • Dual kernels • Hard real-time kernel sits below Linux • Standard interfaces • Real-time kernel traps all interrupts and schedules all • Useful for soft real-time and distributed processes complex applications • Linux runs as a low-priority process • No memory protection between duel kernels • E.g., RT-Linux (FSLabs) • Core kernel modifications • E.g., TimeSys Linux, Monta Vista Linux Chenyang Lu CSE 467S 17 Chenyang Lu CSE 467S 18