1. Defects of the POSIX Sporadic Server and How to Correct Them
Mark Stanovich
Theodore Baker
An-I Wang
Florida State University, USA
Michael González Harbour
Universidad de Cantabria, Spain

2. Overview POSIX specification broken
Budget amplification (accounting error)
Interference can grow over time
Premature replenishment
Invalidates sliding window budget constraint
Incomplete temporal isolation
No way to limit low priority execution

3. Motivation Sporadic server (SS) is well known1 Many uses
Bounds interference for other tasks
Service device drivers
Composable systems
Only POSIX policy that limits CPU time
Alternatives (CBS, TBS, …)
Not for fixed-priority systems
1 Sprunt, Sha, and Lehoczky. Aperiodic task scheduling for hard real-time systems.

4. Sporadic Server Used to service aperiodic jobs
in fixed-priority task scheduling
Interference like a periodic task
Period = replenishment period
Execution time = initial budget
Average response time < polling server
Interference < deferrable server

5. (work available for server)
Replenishment Policy
replenishment period
replenishment
initial budget
time
activation time
(work available for server) 5

6. Bandwidth Preservation
replenishment period
replenishment
initial budget
time
activation time
(work available for server) 6

7. SCHED_SPORADIC POSIX variant Differences
Conceptually similar to Sprunt SS
Differences
Allows overruns
Max execution ≤ available budget + clock resolution
Maximum number of pending replenishments
Background priority

8. Differences Break Model
Budget amplification
Premature replenishment
Incomplete temporal isolation

9. 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”

10. Budget Amplification 10

11. Is this a problem in real systems?

12. Budget Amplification Experiment
Linux sporadic server implementation
Replenishment period = 10 msec
Budget = 1 msec
Budget breaks into 2-8 chunks 12

13. 13

14. How likely is this? Simulate large number of cases
Exponential workload distribution
Mean job execution time = 10
Various mean interarrival times
Server
Replenishment period = 120
Budget = 40
Job overruns = 1 time unit
Maximum utilization = 34% 14

15. 15

16. Solutions Just allow negative available capacity? Our solution
But overruns can still occur every period
Our solution
Think of overrun as time received early
Charge against future replenishments

17. 17

18. Premature Replenishment
Illegal merging of chunks
Violates minimum offset
Exceeds sliding window
budget constraint
Single activation time
is oversimplification

19. Premature Replenishment

20. Premature Replenishment Simulation Experiment
Two tasks
Sporadic server
Replenishment period = 100
Budget = 42
Higher priority periodic task
Period = 141
Execution time specified by x-axis
Intuition
Longer preemption period can trigger illegal merging of time chunks 20

21. 21

22. Is this likely?
Difficult to demonstrate on random arrivals and execution times
Effect does not occur often enough to be measured on a macroscopic scale
This anomaly would probably be only a concern in a hard real-time environment 22

23. Solutions Maintain all replenishments separately?
Unbounded fragmentation
Merging chunks essential
Limits fragmentation
Must not merge illegally
Preserve additional activation times

24. Premature Replenishment
15 minute point
If running behind cut 17-21

25. 25

26. Lessons Learned
Transforming a theoretical algorithm into an implementation is not trivial
Practical considerations
Overruns
Maximum number of replenishments …

27. Lessons Learned
Implementation deviation from theoretical model invalidates schedulabilty analysis
Analysis must be extended to match implementable reality
Implementation must be analyzable 27

28. Conclusion POSIX formulation of SS broken
Provided possible corrections
Need a standard scheduling policy that enforces time budgets
API for SCHED_SPORADIC with correct semantics can serve the purpose

29. Thank You! Questions?

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

31. Unreliable Temporal Isolation
Highest Priority
SCHED_FIFO
SCHED_RR
SCHED_SPORADIC
SCHED_OTHER
Lowest Priority 31

32. Unreliable Temporal Isolation
No upper bound on execution time consumed by SCHED_SPORADIC task
Even though SCHED_OTHER tasks are not RT, should allow a mechanism to isolate from overruns of SCHED_SPORADIC threads 32

33. Unreliable Temporal Isolation
Some remedies
Background execution of SCHED_SPORADIC
Only use idle time
Interleave with non-real-time priorities
Never execute at background priority
Utilize numeric priority to specify functionality 33

34. Solution Highest Priority SCHED_SPORADIC (background priority)
SCHED_FIFO
SCHED_RR
SCHED_SPORADIC (high priority)
SCHED_OTHER
Lowest Priority
Idle
No execute 34

35. Sprunt Defect

36. Overview Aperiodic Tasks
Arrivals and executions are generally considered random
No bound on the CPU runtime
Typically scheduled with a server thread to bound CPU consumption and ease analysis

37. Aperiodic Server
Given a budget which it consumes while executing aperiodic jobs
Budget is replenished according to the server's rules
Typically the server's impact is analyzed by some equivalent periodic task
Examples of fixed-priority servers
Polling Server
Deferrable Server
Sporadic Server

38. Polling Server Ts replenishment server budget time job arrival
Server activations every period (Ts)
ti+1 – ti = Ts

39. Primitive Sporadic ServerTs
replenishment
server budget
time
job arrival
Server activations lower bounded by the period (Ts)
ti+1 – ti ≥ Ts

40. Sporadic Server Parameters Replenishments performed in chunks
Execution budget (Cs)
Replenishment period (Ts)
Server priority
Replenishments performed in chunks
Used execution time is replenished Ts in the future from the server activation

41. POSIX Portable Operating System Interface [for uniX]
Standard that defines a set of services that an operating system provides to an application
Eases portability of applications from one platform to another
Widely implemented
Linux
Mac OS X
OpenBSD
FreeBSD …
Some interfaces are optional (e.g. SCHED_SPORADIC)

42. Budget Amplification
Occurs during overload when all budget is continuously consumed
With small enough fragments, a server can achieve an execution capacity arbitrarily close to 100%
POSIX only limits the available execution capacity to the initial budget
Overruns can happen
Control of execution on the processor cannot be assumed to be perfect
If overruns do occur, then some fairness mechanism should be used

43. sched_ss_repl_period
SCHED_SPORADIC
sched_ss_repl_period
replenishments pending limited to sched_ss_repl_max
replenishments
sched_ss_init_budget
time
activation
time
Current budget limited to sched_ss_init_budget

44. Evaluation Linux implementation Also, simulator
Allows reduction of “noise” from implementation
Demonstrate effects and effectiveness of proposed solutions
Budget amplification
Premature replenishment

45. Effects of Budget Amplification
Experiment does not reach 100% CPU utilization due to replenishments overlapping and therefore merged
Merging two chunks that exceed the initial budget must be rounded down to the initial budget
While there is a bound it still exceeds the load of an equivalent periodic task