Improved implementation of a Deadline Monotonic algorithm for aperiodic traffic scheduling on a two-tired network architecture

Implementation of a
Deadline
Monotonic
based algorithm for
aperiodic traffic scheduling
on a two-tired network
architecture
Davide Giuseppe Monaco
Andrea Tino
Università degli Studi di Catania
Facoltà di Ingegneria Informatica
2010
Real Time Systems
End course project report
Prof. L. LoBello
Eng. E. Toscano
Supervisor
Assistant supervisor
Architectural review: v2

Architecture enhancement
Previous architecture, Enhancements, Main goals, Expected results,
Simulation path
Past architecture
In the previous implemented architecture we proposed a model to schedule and serve aperiodic flows using
Deadline Monotonic in the Polling Server on FAPs. The solution provided a way for analyzing the worst case
scenario where an aperiodic flow spawns in a node, right a moment after its turn to speak. Although the final
architecture was able to manage aperiodic flows, imperfections were found when simulating high stressing
factors, in particular considering the aperiodic traffic intensification.
Queue overload phenomenon
Queue Overload, as addressed in the previous report, was the most alarming problem detected in this
architecture, consisting in an increasing amount of aperiodic flows, having the highest relative deadlines (so
the lowest priority), and stagnating in the pending queue because of the other flows (having a lower relative
deadline and being served before).
Enhanced architecture
In order to nullify the Queue Overload phenomenon, the architecture has been modified, defining, in Nodes, a
different probabilistic aperiodic flow generation policy.
When a node, during its slot to speak in, produces an aperiodic flow (according to the probabilities defined
for the present simulation), a limit is set for it to speak again, always during its turn. This limit is the highest
response time evaluated by Admission Control when accepting a new flow generator. Everytime a new node
joins the network, the response time analysis is performed in order to check whether the node set is still
schedulable; when accepted, the stored max response time is updated.
A node will not produce any flow until the max response time passes by.
Aims and main objectives
The goal is trying to reduce the Queue Overload phenomenon and incrementing the served ratio during all
simulations. By doing that, it is possible to allow the network be more robust during traffic overloads.
Expectations
The proposed enhancement has been applied and the architecture modified as well. We expect to get a
considerable reduction of the deadline miss number and a noticeable served ratio rise.
Real Time Systems 2010 - Final Report (v2)
Davide Giuseppe Monaco, Andrea Tino
Pag. 2

Simulating again
We’ll proceed on simulaing the same scenarios defined in the previous report; by doing that, it will be possible
to compare results and evaluate how much such enhancements really weigh upon network performance.
monitoring queue overload
Queue Overload phenomenon will be tracked, during simulations, in order to verify its effective reduction.
Real Time Systems 2010 - Final Report (v2)
Pag. 3

Simulation eaS-298993
Simulation main goal: Deadline Monotonic stressing attempt evaluating Queue
Overload phenomenon
Simulation duration: 15.000 simulation time units
Machine type: Pentium M 1.4 GHz, one core one CPU, Debian Linux 2.6.26
Simulation information and results
In this simulation, our aim is trying to produce a heavvy stress on Deadline Monotonic scheduling algorithm,
leading the system to a more deadline prone configuration.
Scenario parameters
Simulation has been configured using the following values:
Min (nominal) value Max value
Slot number 20 slots
Aperiodic generation
threshold (T1)
0.8 0.9
Server capacity 5 slots
Aperiodic deadline
definition threshold (T2)
40 slots 60 slots
Flow generator
spawning threshold (T3)
1.0
Final considerations
This scenario, the worst case scenario as addressed in the previous report, does not change a bit. Compared
with S-298993 simulation, we have zero differences. This result probably tells us that, even considering
enhancements, the Queue Overload phenomenon occurs with the same characteristics and peculiarities. In
our simulations we’ll try to reach this case incrementing aperiodic generation thresholds.
Real Time Systems 2010 - Simulations (v2)
Pag. 4
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

Simulation main goal: Low variation of relative deadline
In this simulation, our aim is monitoring our network and see how efficently Polling Server can schedule
aperiodi flows having similar deadlines (low variation factor).
Scenario parameters
threshold (T1)
0.1 0.3
Aperiodic deadline
40 slots 50 slots
Flow generator
1.0
Final considerations
Even the best case scenario does not report any changes, numeric values remains the same of the ones
reported in the previous report.
Somehow this is a predictable result: the worst and the best case are two extremes of a simulation space that
has not changed, and we want this to happen because the main goal is observing how this space gradually
modifies internally, generating a different variety of conditions, which we hope being better than before.
Pag. 5
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

Simulation main goal: Low number of slots, same probability of aperiodic
notification transmission
Simulating scenario eaS-297555:s01
aperiodic flows having a low capacity.
Scenario parameters
threshold (T1)
0.19 0.21
Aperiodic deadline
20 slots 40 slots
Flow generator
1.0
Results about flow generators
During simulation, Admission Control’s activity about registration request management is summarized below:
Total requests Admitted Rejected
34 8 26
Results about aperiodic flows
Polling Server statistics regarding aperiodic flows management are shown below:
Total received flows Served Deadline Misses Served ratio
1566 1505 59 0.96
Considerations about scenario
We have a decrease in the number of received flows, this result was expected because of the limit to transmit
again for a node. Furthermore it is possible to experience an improvement in performance thanks to the
served ratio increment (previous value: 0.95). Note also that the number of deadline misses decrease too
(previous value: 90).
Pag. 6
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

In this simulation we increment deadline thresholds in order to intensify traffic in the network.
Scenario parameters
threshold (T1)
0.34 0.36
Aperiodic deadline
20 slots 40 slots
Flow generator
1.0
36 8 28
2239 1987 247 0.88
Admission Control receives more admission requests. It is noticeable a serious increase of the served ratio
(previous value: 0.76), together with a considerable fall of the deadline misse number (previous value: 607).
In this simulation we still increment deadline thresholds in order to intensify traffic in the network.
Scenario parameters
threshold (T1)
0.44 0.46
Aperiodic deadline
20 slots 40 slots
Pag. 7
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

Flow generator
1.0
26 8 14
2561 2097 458 0.82
We keep on experiencing a considerable decrease of the number of deadline misses. Served ratio falls by a
very small percentage mainaining on a very high and unexpected level.
In this simulation we take deadline thresholds to a 20% higher level.
Scenario parameters
threshold (T1)
0.64 0.66
Aperiodic deadline
20 slots 40 slots
Flow generator
1.0
19 8 11
Pag. 8
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

3066 2003 719 0.65
Although a considerable served ratio fall, making comparisons with the previous simulation, is experienced;
the served ratio value maintains upon the 50% threshold, while, in the previous architecture, we encountered
a much higher decrease (served ratio previous value: 0.50).
In this simulation we take deadline thresholds to about 10% higher level, reaching the final stage.
Scenario parameters
threshold (T1)
0.79 0.81
Aperiodic deadline
20 slots 40 slots
Flow generator
1.0
26 8 18
3338 2076 646 0.62
We have the confirmation that, for this class of scenarios, the new architecture produces a better service.
Served ratio maintains upon 60% while in the previous architecture we reached 47%.
Final considerations about overall simulation
Our expectations have not been contradicted. Network performance increase and served ratio decrease, as
traffic intensifies, by a smaller falling coefficient.
Pag. 9
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

Although this scenario is the simplest one, we must not forget that the microcycle has a very low duration, this
surely affects system performance creating a worse condition. Thanks to the enhanced architecture, this class
of scenarios shows a positive change in the system trend.
This chart shows the mean response time for some flow generators characterized by different relative deadlines and arrival times. The
x-axis shows the increasing level of the aperiodic flow generation threshold.
Pag. 10
10
20
30
40
50
60
70
80
t=0.8t=0.65t=0,45t=0.35t=0,2
D = 22, r = 9
D = 22, r = 21
D = 23, r = 4
D = 24, r = 3
D = 30, r = 8
D = 33, r = 5
D = 36, r = 6

Simulation main goal: Medium number of slots, same probability of aperiodic
aperiodic flows having a low capacity. In this scenario, we consider a wider microcycle.
Scenario parameters
threshold (T1)
0.19 0.21
Aperiodic deadline
40 slots 80 slots
Flow generator
1.0
15 15 0
3013 3010 0 1
There are 3 missing flows, they were in the pending queue ready to be served when simulation stopped.
This simulation reports a served ratio equal to the one in the previous architecture with the same deadline
miss number and the same served ratio. Nothing more to point out.
Pag. 11
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

In this simulation, we will take the aperiodic generation threshold to a higher value in order to monitor network
response and performance.
Scenario parameters
threshold (T1)
0.34 0.36
Aperiodic deadline
40 slots 80 slots
Flow generator
1.0
15 15 0
4362 4357 0 1
We have the same situation, the pending queue contains some elements that were ready to be served when
the simulation stopped, it is not the symptom of the Queue Overload phenomenon.
We can simply notice, comparing this scenario with the same in the previous architecture, that the system is
more stable; furthermore, the number of deadline misses decrease to 0.
This scenario to stress further the scheduling algorithm by intensifying the network traffic.
Scenario parameters
Pag. 12
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

threshold (T1)
0.44 0.46
Aperiodic deadline
40 slots 80 slots
Flow generator
1.0
15 15 0
5071 5064 0 0.99
As before, as simulation stopped, some notifications were ready to be served in the pending queue.
Here, we have the first significant change with the previous architecture. Served ratio pratically unchanges and
the number of deadline misses is zero (when the value in the previous architecture’s scenario was 63).
In this scenario, the aperiodic flow probability is raised in order to reach a more stressing condition for the
network and the scheduling algorithm.
Scenario parameters
threshold (T1)
0.64 0.66
Aperiodic deadline
40 slots 80 slots
Flow generator
1.0
Pag. 13
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

15 15 0
6049 6038 6 0.99
We report an initial number of deadline misses, there are some flows that, when simulation stopped, were
ready to be served in the pending queue.
With a high stressing factor, represented by the increasing traffic intensity, we experience a global non
variation of the most important performance parameters: served ratio unchanges as the number of deadline
misses increases by a very small value (irrilevant).
In this simulation we try to reach the worst case scenario. We will monitor how system responds.
Scenario parameters
threshold (T1)
0.79 0.81
Aperiodic deadline
40 slots 80 slots
Flow generator
1.0
15 15 0
6605 6594 5 0.99
As before, we do not experience the Queue Overload ohenomenon.
Pag. 14
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

This scenario reports an unexpected result. We can experience very high system stability and traffic tolerance;
the number of deadline misses even decreases as the served ratio unchanges.
We can report a successful class of scenarios. Even when heavily stressed by a very intense traffic, the
network is able to keep control on aperiodic flows.
The number of deadline misses is pratically null and the served ratio is always the highest possible one.
The most important thing to point out is that we do not experience the Queue Overload phenomenon
at all. This means that, for this class of scenarios, our objectives have been reached.
x-axis shows the increasing level of the aperiodic flow generation threshold. Among all flow generators, the most significant has been
selected for plotting simulation data.
Pag. 15
20
30
40
50
t=0.8t=0.65t=0,45t=0.35t=0,2
D = 40, r = 19
D = 48, r = 20
D = 50, r = 14
D = 80, r = 13
D = 45, r = 10
D = 58, r = 12
D = 48, r = 7
D = 64, r = 9
D = 64, r = 11
D = 76, r = 16

Simulation main goal: High number of slots, same probability of aperiodic
aperiodic flows having a low capacity but a higher number of flow generators.
Scenario parameters
threshold (T1)
0.19 0.21
Aperiodic deadline
100 slots 200 slots
Flow generator
1.0
57 38 19
7099 7092 0 1
We have some aperiodic notification in the pending queue when the simulation is stopped.
This scenario is pratically the same in the previous architecture.
Pag. 16
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

By incrementing the aperiodic flow generation threshold, we want to test the system robustness to a general
traffic intensification.
Scenario parameters
threshold (T1)
0.34 0.36
Aperiodic deadline
100 slots 200 slots
Flow generator
1.0
51 38 13
11612 11603 0 1
There are elements in the pending queue, but this is not the Queue Overload phenomenon.
We start experiencing some improvements, served ratio does not change and the number of deadline misses
reduces to zero (comparing with the previous architecture).
In this simulation our aim is monitoring the system performance and the scheduling algorithm efficiency when
the aperiodic generation threshold is lead to a medium level.
Scenario parameters
threshold (T1)
0.44 0.46
Pag. 17
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

Aperiodic deadline
100 slots 200 slots
Flow generator
1.0
59 38 21
13331 13317 0 1
Differently from the previous architecture’s scenario, we have no deadline misses and a stable served ratio.
With this simulation we want to get near the worst case scenario in order to see how the system reacts when
conditions get worse.
Scenario parameters
threshold (T1)
0.64 0.66
Aperiodic deadline
100 slots 200 slots
Flow generator
1.0
54 38 16
Pag. 18
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

15831 15792 22 0.99
We still do not encounter the Queue Overload phenomenon.
This scenario defines a milestone in this class of scenarios. From the number of 1056 deadline misses
we experience only 22 misses (a very irrilevant level if we consider that 15831 flows have been received).
Furthermore, the served ratio does not change a bit, even at high levels of stress defined by an increasing
traffic intensity.
In this simulation we reach the worst case scenario.
Scenario parameters
threshold (T1)
0.79 0.81
Aperiodic deadline
100 slots 200 slots
Flow generator
1.0
50 38 12
In this case, differently from the other scenarios, we experience a significant increment of the total number of
requests send to Admission Control.
17206 16958 232 0.98
Looking inside the queue log file, it is possible to see that queues are not full of aperiodic notifications. The
Queue Overload phenomenon does not occur. The missing flows are due to the number of deadline misses
occurred in the simulation.
Pag. 19
0,2
0,4
0,6
0,8
1,0
T3 T1max
T1min

We experience very high performance. Polling Server is able to manage aperiodic flows without causing the
system to suffer any overflow or performance decay.
We can state that the improvements made in the architecture have lead to a very good result even for this
class of scenarios.
We can also state that the Queue Overload phenomenon has been totally nullified thanks to the
enhancements applied to the previous architecture.
x-axis shows the increasing level of the aperiodic flow generation threshold. Among all flow generators, the most significant has been
selected for plotting simulation data.
Pag. 20
40
60
80
100
120
t=0.8t=0.65t=0.45t=0.35t=0.2
D = 114, r = 99
D = 129, r = 39
D = 107, r = 32
D = 147, r = 15
D = 147, r = 23
D = 111, r = 14
D = 116, r = 17
D = 106, r = 29
D = 129, r = 26
D = 195, r = 35

Summarizing simulations
Simulations: eaS-297555, eaS-446696, eaS-896322
Summarizing served ratio
Considering the three simulations it is possible to notice how the last two are equivalent from the point of view
of the served ratio coefficent, while the first simulation experiences a fast performance decay.
Summarizing deadline misses
In the same way of before, let us consider the deadline misses during the 5 scenarios in the three simulations.
It is possible to see that the first simulation generates high levels of deadline misses, while the second and the
This chart shows the served ratio during the 5 scenarios for each simulation.
This chart shows the number of deadline misses during the 5 scenarios for each simulation.
Pag. 21
eaS-297555
0,6
0,8
1,0
t = 0.8t = 0.65t = 0.45t = 0.35t = 0.2
eaS-446696
eaS-896332
S-297555
0
100
200
300
400
500
600
700
800
t = 0.8t = 0.65t = 0.45t = 0.35t = 0.2
S-446696
S-896332

last simulation are able to produce a lower number of misses. In particular, it is possible to notice a peak in the
last simulation. It is possible to say, in a final analysis, that the most stable configuration is the one provided
for scenario ea446696.
Pag. 22

Log files and logging rules
In order to produce statistics about a particular simulation and show its data for analysis and other purposes,
some files are written when a scenario is stopped.
Log file names
All log files are named using the following rule:
[option]log[_<component>]_<simulation_id>.log
where:
• Option is a character or a sequence of character used for special log files.
• Component is the name of the component who wrote that file (meaning also that the file will contain
information regarding that particular component in the network). Available possibilities are:
1. Polling Server: using the “ps“ character sequence.
2. Admission Control: using the “ac“ character sequence.
3. Nodes: using the “n“ character.
• Simulation ID is the simulated scenario identifier consisting in an integer number (uniqie for every
simulated scenario)
If the same simulation is run again, its log files will be overwritten.
If a brand new simulation is started its log files will be created in the same directory of the OMNeT++ project.
Log files
Each simulation (we take as example the simulation id 001) creates these log files:
1. Polling Server log file (example: log_ps_001.log): This file is written by Polling Server everytime that a
significant event occurs and at the end of the simulation. At runtime, the file is filled with lines reporting
the most important events during the simulation (like a deadline miss or a flow to be moved in the pending
queue). The file is finally closed when the simulation finishes; in this case Polling Server appends several
information regarding overall simulated scenario (like the total number of deadline misses) and statistics
about every single flow generator, providing useful information about produced traffic and its main
characterization.
2. Admission Control log file (example: log_ac_001.log): Admission Control writes this file at runtime
everytime that a new flow generator attempts to join the network; in this case the file reports the hesit of
the admission test and the joining generator information. Admission Control finally closes the file when the
simulation finishes, writing final considerations about admission tests.
3. Nodes log file (example: log_n_001.log): Nodes writes this file when the simulation is stopped. The file
stores the most important information about flow generators settings (like the total number of generated
flows). The final part of the file is reserved for list of the flow generators sorted by their relative deadline
(as they are during Deadline Monotonic algorithm execution).
Real Time Systems 2010 - Appendixes (v2)
Appendix

4. Queues log file (example: qlog_001.log): This file is written by Polling Server and provides a way for
looking inside the waiting and the pending queue during every beacon slot. This file can be used for
checking ther queues’ state after the simulation.
Logging functions
To implement logging functionality, the source files in the project are filled with special private member
functions and variables recognizable by the “log“ prefix. It is highly recommended not to modify these functions
in order not to loose the logging system (tested at development time).
Appendix

Simulation reports’ glossary
The simulations section of this document shows several data structures, tables and charts in order to present
simulation results in the most affordable and easy to understand way. Some acronyms and abbreviations are
present though.
Abbreviations and symbols
Abbreviations and special character symbols used in simulation reports are the following (attention, all
abbreviations are case sensitive):
Abbreviation Places to find it Description
Tot Table headers Indicates the total number of flows generated by a particular
flow generator
D Table headers Indicates the relative deadline of a particular flow generator.
r Table headers Indicates the arival time of an aperiodic flow or the arrival time
of a flow generator (attempting to join the network) registration
message.
WCRT Table headers Indicates the Worst Case Response Time evaluated by
Admission Control when admitting a new flow generator.
Pr{Tx} Table headers Indicates the probability to transimt an aperiodic flow for a flow
generator.
R.T. Table headers Indicates the Response Time of a flow (scheduled and served
by Polling Server).
σ Table headers Indicates the standard deviation.
delay Table headers Indicates the range of time starting from when an aperiodic flow
is created to the time when it is served.
Min Table headers Indicates the minimum numeric value inside a series of
numbers.
Max Table headers Indicates the maximum numeric value inside a series of
numbers.
FG Table headers, tables side
cells
Indicates a flow generator (usually followed by its numeric
identifier).
APE Paragraph bodies Indicates an aperiodic flow.
Delay time
In simulations we refer to delay time as the interval between the absolute deadline and the finishing time
(instant when a flow is served). To calculate delay we apply the simple formula: delay = abs_deadline -
finish_time. When dealy is positive it means that the flow has been served in time and delay reports how much
before the flow has been managed (defore its deadline). If the value is negative, we have a deadline miss
reported after delay time units.
Appendix

Improved implementation of a Deadline Monotonic algorithm for aperiodic traffic scheduling on a two-tired network architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (12)

Similar to Improved implementation of a Deadline Monotonic algorithm for aperiodic traffic scheduling on a two-tired network architecture

Similar to Improved implementation of a Deadline Monotonic algorithm for aperiodic traffic scheduling on a two-tired network architecture (20)

More from Andrea Tino

More from Andrea Tino (20)

Recently uploaded

Recently uploaded (20)

Improved implementation of a Deadline Monotonic algorithm for aperiodic traffic scheduling on a two-tired network architecture