Sporadic Server Scheduling in Linux
Theory vs. Practice
Mark Stanovich
Theodore Baker
Andy Wang
Real-Time Scheduling Theory
• Analysis techniques to design a system to
meet timing constraints
• Schedulability analysis
– Workload models
– Processor models
– Scheduling algorithms
Real-Time Scheduling Theory
• Analysis techniques to design a system to
meet timing constraints
• Schedulability analysis
– Workload models
– Processor models
– Scheduling algorithms
Periodic Task
Task = {T, C, D}
jobs (j1, j2, j3, …)
Deadline = D
time
Period = T
Computation time
WCET = C
Release time
Periodic Task
sched_setscheduler(SCHED_FIFO)
time
clock_nanosleep()
Periodic Task
• Assumptions
– WCET is reliable
– Arrivals are periodic
• Not realistic for most tasks
Polling Server
Replenishment period
time
Job arrivals
Initial
budget
time
Polling Server
• Type of aperiodic server
• CPU usage no worse than an equivalent
periodic task
– Can be modeled as a periodic task
• WCET = Initial Budget
• Period = Replenishment Period
• Budget consumed as CPU time is used
– CPU time forfeited if not used
• Replenish budget every period
Polling Server
• Good
– Bounds CPU usage
– Analyzable workload model
– Simplicity
• Can be better
– Faster response time if budget is not forfeited
Sporadic Server
Replenishment period
time
Job arrivals
Initial
budget
time
replenishments
Sporadic Server
• Originally proposed by Sprunt et. al.
• Parameters
– Initial budget
– Replenishment period
• Bounds max CPU interference for other tasks
• Fits into the periodic task workload model
• Better avg. response time than polling server
Sporadic Server
• Scheduling algorithm for fixed-task-priority
systems
– Can be used in UNIX priority model
• SCHED_SPORADIC is a version of SS defined in
POSIX definition
– POSIX variant has some errors
– Corrected version in another paper
Implementation
• Linux 2.6.38
– Sporadic server implementation
• Corrected version
– Softirq threading patch ported from earlier RT
patch
• Only tested on uniprocessor
Sporadic Server Performance
• Metrics
– CPU interference for lower priority tasks
– Average response time
An Experiment
A
Sends UDP packet with
current timestamp
B
Receives UDP packets
Calculate response time based on
arrival at UDP layer
Measure CPU time for 10 second burst
Measuring CPU Time
• Regehr's “hourglass” technique
– Constantly read time stamp counter
– Detect preemptions by large diff in read time
– Sum execution chunks
• Hourglass thread lower than net-rx thread
• Measures interference from net-rx thread
Measuring CPU Time
• Network receive thread
– SCHED_FIFO
– Sporadic and polling server
• Budget = 1 msec
• Period = 10 msec
• Hourglass thread
– SCHED_FIFO
– Lower priority than network receive thread
CPU Utilization
Average Response Time
Average Response Time
Interference
• CPU usage not limited properly
• Additional overheads
– Context switch time
– Cache eviction and reloading
• Not in theoretical workload model
• Guarantees of theory require interference to
be included in the analysis
Polling Server
= aperiodic job arrival
= aperiodic job CPU time
SSbudget + 2  CStime 
time
Sporadic Server
= aperiodic job arrival
= replenishment period
= aperiodic job CPU time
SSbudget + 2  CStime  max_repl 
time
Over Provisioning
• All context switch time may not be used
– e.g., one replenishment per period
• Better solution
– Account for CS time on-line
– Charge SS for each preemption
CPU Utilization
Average Response Time
Average Response Time
Can we get the best of both?
Sporadic Sever
–Light Load
–Low response time
Polling Sever
–Heavy Load
–Low response time
–No dropped pkts
Hybrid Server
• How to switch
– SS with 1 replenishment is same as polling server
– Coalesce replenishments
– Ensure bounded interference
• Push replenishments further into the future
• Switching point
– Server has work but no budget
Coalescing Replenishments
Out of budget
Work available
time
Coalescing Replenishments
Out of budget
Work available
time
Average Response Time
CPU Utilization
Switching Between Modes
• Immediate coalescing may be too extreme
– CPU time could be used for better response time
• Gradual approach
– Coalesce fewer replenishments at a time
Gradual Coalescing
Out of budget
Work available
time
Gradual Coalescing
Out of budget
Work available
time
Gradual Coalescing
time
Average Response Time
CPU Utilization
Conclusion
• Theoretical analysis provides solid guarantees
• Implementation must match abstract models
– Additional interference terms need to be
considered
– SS can fit into the theoretical analysis
• CPU interference experienced by both SS and
preempted task
Questions?
Differences Break Model
• Budget amplification
• Premature replenishment
• Incomplete temporal isolation
42
Budget Amplification
• Accounting error
– Overruns not always charged to the server
• Max execution ≤ server budget + clock res.
• “if the available execution capacity would
become negative...it shall be set to zero”
43
Budget Amplification
44
Premature Replenishment
45
Defect #3: Incomplete Temporal Isolation
• With temporal isolation a failure in one task
does not prevent others from meeting their
timing constraints
• Problem: Execution at low priority
– Still preempts non-”real-time” work
46
Unreliable Temporal Isolation
Highest
Priority
SCHED_FIFO
SCHED_RR
SCHED_SPORADIC
SCHED_OTHER
Lowest
Priority
47
Deferrable Server
Deferrable Server
Bandwidth Preserving




Allow server to retain budget
Periodically replenish budget
WCET != Budget
Response Time
Replenishment Policy
replenishment
replenishment period
initial
budget
time
arrival time
(work available for server)
Bandwidth Preservation
replenishment
replenishment period
initial
budget
time
arrival time
(work available for server)
Sporadic Server
time
Analysis

Light load
– Sporadic Server
• Low response time
– Polling Server
•High response time

Heavy load
– Sporadic Server
•High response time
•Dropped packets
– Polling Server
•Low response time
•No dropped packets