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

Implementation of aDeaDline Monotonicbased algorithm for aperiodic traffic scheduling on a two-tired network architecture

DaviDe Giuseppe Monaco

anDrea Tino

Università degli Studi di CataniaFacoltà di Ingegneria Informatica2010

Real Time SystemsEnd course project report

Prof. L. LoBello

Eng. E. Toscano

Supervisor

Assistant supervisor

Architectural review: v2

Architecture enhancementPrevious architecture, Enhancements, Main goals, Expected results, Simulation path

Past architectureIn 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 PhEnoMEnonQueue 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 architectureIn 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 objectivesThe 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.

ExpectationsThe 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 againWe’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 ovErLoadQueue Overload phenomenon will be tracked, during simulations, in order to verify its effective reduction.

Real Time Systems 2010 - Final Report (v2)Davide Giuseppe Monaco, Andrea Tino

Pag. 3

Simulation eaS-298993Simulation 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 resultsIn 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 ParaMETErSSimulation has been configured using the following values:

Min (nominal) value Max valueSlot number 20 slotsaperiodic generation threshold (T1)

0.8 0.9

Server capacity 5 slotsaperiodic deadline definition threshold (T2)

40 slots 60 slots

Flow generator spawning threshold (T3)

1.0

Final considerationsThis 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)Davide Giuseppe Monaco, Andrea Tino

Pag. 4

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

Simulation eaS-179462Simulation main goal: Low variation of relative deadline 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 resultsIn this simulation, our aim is monitoring our network and see how efficently Polling Server can schedule aperiodi flows having similar deadlines (low variation factor).



0.1 0.3


40 slots 50 slots


1.0

Final considerationsEven 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 eaS-297555Simulation main goal: Low number of slots, same probability of aperiodic notification transmission Simulation duration: 15.000 simulation time units Machine type: Pentium M 1.4 GHz, one core one CPU, Debian Linux 2.6.26

Simulating scenario eaS-297555:s01Simulation information and resultsIn this simulation, our aim is monitoring our network and see how efficently Polling Server can schedule aperiodic flows having a low capacity.



0.19 0.21


20 slots 40 slots


1.0

rESuLTS aBouT FLow gEnEraTorSDuring simulation, Admission Control’s activity about registration request management is summarized below:

Total requests admitted rejected34 8 26

rESuLTS aBouT aPEriodic FLowSPolling Server statistics regarding aperiodic flows management are shown below:

Total received flows Served deadline Misses Served ratio1566 1505 59 0.96

Considerations about scenarioWe 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).

Simulating scenario eaS-297555:s02


Pag. 6

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

Simulation information and resultsIn this simulation we increment deadline thresholds in order to intensify traffic in the network.



0.34 0.36


20 slots 40 slots


1.0





Considerations about scenarioAdmission 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).

Simulating scenario eaS-297555:s03Simulation information and resultsIn this simulation we still increment deadline thresholds in order to intensify traffic in the network.



0.44 0.46


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

Min (nominal) value Max valueFlow generator spawning threshold (T3)

1.0





Considerations about scenarioWe 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.

Simulating scenario eaS-297555:s04Simulation information and resultsIn this simulation we take deadline thresholds to a 20% higher level.



0.64 0.66


20 slots 40 slots


1.0





Pag. 8

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min


Considerations about scenarioAlthough 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).

Simulating scenario eaS-297555:s05Simulation information and resultsIn this simulation we take deadline thresholds to about 10% higher level, reaching the final stage.



0.79 0.81


20 slots 40 slots


1.0





Considerations about scenarioWe 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 simulationOur 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 = 9D = 22, r = 21

D = 23, r = 4

D = 24, r = 3D = 30, r = 8

D = 33, r = 5D = 36, r = 6

Simulation eaS-446696Simulation main goal: Medium number of slots, same probability of aperiodic notification transmission Simulation duration: 30.000 simulation time units Machine type: Pentium M 1.4 GHz, one core one CPU, Debian Linux 2.6.26

Simulating scenario eaS-446696:s01Simulation information and resultsIn this simulation, our aim is monitoring our network and see how efficently Polling Server can schedule aperiodic flows having a low capacity. In this scenario, we consider a wider microcycle.



0.19 0.21


40 slots 80 slots


1.0




Total received flows Served deadline Misses Served ratio3013 3010 0 1

There are 3 missing flows, they were in the pending queue ready to be served when simulation stopped.

Considerations about scenarioThis 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.

Simulating scenario eaS-446696:s02


Pag. 11

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

Simulation information and resultsIn this simulation, we will take the aperiodic generation threshold to a higher value in order to monitor network response and performance.



0.34 0.36


40 slots 80 slots


1.0





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.

Considerations about scenarioWe 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.

Simulating scenario eaS-446696:s03Simulation information and resultsThis scenario to stress further the scheduling algorithm by intensifying the network traffic.


Min (nominal) value Max valueSlot number 20 slots


Pag. 12

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

Min (nominal) value Max valueaperiodic generation threshold (T1)

0.44 0.46


40 slots 80 slots


1.0





As before, as simulation stopped, some notifications were ready to be served in the pending queue.

Considerations about scenarioHere, 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).

Simulating scenario eaS-446696:s04Simulation information and resultsIn this scenario, the aperiodic flow probability is raised in order to reach a more stressing condition for the network and the scheduling algorithm.



0.64 0.66


40 slots 80 slots


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




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.

Considerations about scenarioWith 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).

Simulating scenario eaS-446696:s05Simulation information and resultsIn this simulation we try to reach the worst case scenario. We will monitor how system responds.



0.79 0.81


40 slots 80 slots


1.0





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

Considerations about scenarioThis 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.

Final considerations about overall simulationWe 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.

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. 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 = 10D = 58, r = 12

D = 48, r = 7D = 64, r = 9

D = 64, r = 11D = 76, r = 16

Simulation eaS-896332Simulation main goal: High number of slots, same probability of aperiodic notification transmission Simulation duration: 75.000 simulation time units Machine type: Pentium M 1.4 GHz, one core one CPU, Debian Linux 2.6.26

Simulating scenario eaS-896322:s01Simulation information and resultsIn this simulation, our aim is monitoring our network and see how efficently Polling Server can schedule aperiodic flows having a low capacity but a higher number of flow generators.



0.19 0.21


100 slots 200 slots


1.0





We have some aperiodic notification in the pending queue when the simulation is stopped.

Considerations about scenarioThis scenario is pratically the same in the previous architecture.

Simulating scenario eaS-896322:s02Simulation information and results


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.



0.34 0.36


100 slots 200 slots


1.0





There are elements in the pending queue, but this is not the Queue Overload phenomenon.

Considerations about scenarioWe start experiencing some improvements, served ratio does not change and the number of deadline misses reduces to zero (comparing with the previous architecture).

Simulating scenario eaS-896322:s03Simulation information and resultsIn 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.



0.44 0.46

Server capacity 12 slots


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

Min (nominal) value Max valueaperiodic deadline definition threshold (T2)

100 slots 200 slots


1.0





Considerations about scenarioDifferently from the previous architecture’s scenario, we have no deadline misses and a stable served ratio.

Simulating scenario eaS-896322:s04Simulation information and resultsWith this simulation we want to get near the worst case scenario in order to see how the system reacts when conditions get worse.



0.64 0.66


100 slots 200 slots


1.0





Pag. 18

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min


We still do not encounter the Queue Overload phenomenon.

Considerations about scenarioThis 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.

Simulating scenario eaS-896322:s05Simulation information and resultsIn this simulation we reach the worst case scenario.



0.79 0.81


100 slots 200 slots


1.0



In this case, differently from the other scenarios, we experience a significant increment of the total number of requests send to Admission Control.



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

Considerations about scenarioWe experience very high performance. Polling Server is able to manage aperiodic flows without causing the system to suffer any overflow or performance decay.

Final considerations about overall simulationWe 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.

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. 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 = 39D = 107, r = 32

D = 147, r = 15

D = 147, r = 23

D = 111, r = 14D = 116, r = 17

D = 106, r = 29

D = 129, r = 26

D = 195, r = 35

Summarizing simulationsSimulations: eaS-297555, eaS-446696, eaS-896322

Summarizing served ratioConsidering 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 missesIn 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 rulesIn 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 naMESAll 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 FiLESEach 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)Davide Giuseppe Monaco, Andrea Tino

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 FuncTionSTo 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’ glossaryThe 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 SyMBoLSAbbreviations and special character symbols used in simulation reports are the following (attention, all abbreviations are case sensitive):

Abbreviation Places to find it descriptionTot Table headers Indicates the total number of flows generated by a particular

flow generatord 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

cellsIndicates a flow generator (usually followed by its numeric identifier).

aPE Paragraph bodies Indicates an aperiodic flow.

dELay TiMEIn 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

Technology

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