1

Defects of the POSIX Sporadic Server and How to Correct Them

Mark StanovichTheodore Baker

An-I WangFlorida State University, USA

Michael González HarbourUniversidad 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

Replenishment Policy

replenishment period

replenishment

initial budget

time

activation time(work available for server)

6

Bandwidth Preservation

replenishment period

replenishment

initial budget

time

activation time(work available for server)

7

SCHED_SPORADIC

• POSIX variant– 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

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

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%

120

140

15

16

Solutions

• Just allow negative available capacity?– But overruns can still occur every period

• Our solution– Think of overrun as time received early– Charge against future replenishments

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

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

23

Solutions

• Maintain all replenishments separately?– Unbounded fragmentation

• Merging chunks essential– Limits fragmentation

• Must not merge illegally– Preserve additional activation times

24

Premature Replenishment

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

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

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

31

Unreliable Temporal Isolation

SCHED_FIFOSCHED_RR

SCHED_SPORADIC

SCHED_OTHER

Highest Priority

Lowest Priority

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

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

34

Solution

Highest Priority

Lowest Priority

Idle

No execute

SCHED_OTHER

SC

HE

D_S

PO

RA

DIC

(background priority)SCHED_FIFOSCHED_RR

SCHED_SPORADIC (high priority)

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

server budget

T s

time

replenishment

job arrival

Server activations every period (Ts)

ti+1 – ti = Ts

39

Primitive Sporadic Server

server budget

T s

time

replenishment

job arrival

Server activations lower bounded by the period (Ts)

ti+1 – ti ≥ Ts

40

Sporadic Server

• Parameters– 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_SPORADIC

sched_ss_repl_period

time

replenishments

activationtime

replenishments pending limited to sched_ss_repl_max

Current budget limited to sched_ss_init_budget

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