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

Architecture outlineIntroduction to our project, Flexware architecture overview, overall components and parts of interest

Project and main objectivesOur project consists in designing and simulating a simpified two tired network (based on the Flexware architecture), in order to produce statistics about aperiodic real time traffic handled by certain nodes. By doing so, our most important goal is achieving knowledge about how efficiently the entire system can manage alarms and one-shot real time traffic, respecting time constraints.

To simulate such a network, the Eclipse based Omnet++ environment has been used, building and simulating nodes and other components using C++ and NED languages.

Flexware architectureThe simulated network is based on the Flexware architecture, a real time wireless/wired network for industrial purposes; for this reason, our project is bound to some special nodes and components that has been created in our simulations.

Two-TIrEd schEmEFlexware network’s goals are mostly focused on allowing real time traffic transmission on wireless physical layer; given the large amount of problems concerning time constraints, a pure wireless connection cannot guarantee efficent trasmission of such a data stream type; thus, an hybrid approach is needed, providing a wired level connection for FAPs (Flexware Access Points: those components managing wireless cells) managed by one or more FCs (Flexware Controllers: those components managing real time flows scheduling), and a wireless level for FNs (Flexware Nodes: those nodes responsible for creating real time traffic).

Subsystem simulationOur simulations focus only on a subsystem of the overall one described before; in particular, our aim is implementing a Dealine Monotinic scheduling algorithm on the Polling Server of FAPs, in order to manage aperiodic real time flows. For this reason, only these components are considered in the simulated network:

• FNs: Traffic generators are considered in order to simulate aperiodic traffic generation.

• FAPs: Middleware components are considered in order to implement, there, the scheduling algorithm.

TImE dIvIsIon muLTIPLE AccEssTDMA is implemented on Flexware architecture in order to let nodes not interfere with others when sending their own flows. This time sharing mechanism is located in the middleware level, FCs are responsible for managing node traffic schedulation.

Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea Tino

Pag. 2

Simulated architectureComponents and simulated parts, Dynamics and data flows

Components in simulationThe simulated network works using four main components:

• Nodes: This component in connected to Polling Server and Admission Control, it contains a variable number of Nodes (for each simulation) able to generate aperiodic traffic to be scheduled. It is possible to figure out this part of the network as an array of flow generators and, from now on, we will act this way.

• Pollig Server: It is connected to Nodes only and acts as a flow scheduler/dispatcher. The Deadline Monotonic sheduling algorithm is built and works inside this component.

• Admission Control: This component is connected to Nodes for incoming flows and to Scheduler for outgoing traffic. Admission Control ensures node registration in order to let Polling Server know how many nodes (and which ones) it is going to handle. This component is also responsible for admission policy, implementing a response time analysis in order to understand whether a new flow generator can be attached to the network, knowing its traffic information.

• Scheduler: This component is connected to Admission Control only, accepting its information regarding


Pag. 3

Admission Control (AC)

Di Ci FNiAperiodic �ow data

Scheduler (SCHED)

t1 t2 tit3 ... ... tn

Beacon �le

Flow Generator

FN1

Flow Generator

FN2

Flow Generator

FNi

Flow Generator

FNn

Polling Server (PS)

fn1 fn2 fn3 ... fni ... fnn

fnj ... fn(j+k) ... fnm

Waiting queue

Pending queue

This diagram shows the simulated network’s architecture. The lowest level is represented by Nodes (all flow generators are implicitily contained inside a component called Nodes, not shown here), the Flexware middleware is represented by PS, SCHED and AC (all

enbodied inside the same virtual component, the FAP, not modeled inside the simulated network). Shown connections match the ones inside the NED file of the simulated network. Furthermore, delayed channels are applied to Nodes/PS connection only.

registered nodes. Scheduler ensures scheduling management (through TDMA slot/node associations), letting everyone in the network know its own slot to “speak“ in.

schEduLATIon FILEInside the simulated network, schedulation data provided by Scheduler is stored in a global file (called beacon.txt). By doing so, it is possible to simulate the beacon sent in broadcast during every microcycle. This file is read by Polling Server and Nodes, and it is written by Scheduler.

no shared resource mutual exclusive access algorithm must be taken into consideration for the beacon file, given that read and write operations are executed in different time slices. We will use the terms: schedulation file and beacon file to refer to this element.

FLow mEssAgEThe simulated network heavily works on message exchange; in order to simulate flow information to be transmitted from Nodes to Polling Server, we use a personal message type called Flow. Thus, our simulations use two message types:

• Flow type: Created through msg OMNeT++ functionality, this message stores the most important information of a flow:

1. Required slots: The number of slots needed by the flow to be managed.

2. Node ID: Identifier of the node (flow generator) which sent that flow.

3. Deadline: Flow’s relative deadline expressed in number of slots.

4. Arrival time: The exact time when the flow is created by its generator.

From now on, the term Flow will refer to this message type in simulations.

• cMessage type: OMNeT++ basic message type used in simulation for management data (like bootstrap messages for clock initialization).

FLow gEnErATorsFlow generators represent a simplified way to emulate all nodes in the network. One generator is responsible for creating aperiodic real time traffic to be handled.

All flows produced by a generator have the same relative deadline; this is a very important hypothesis when dealing with response time analysis during admission test.

Simulation dynamics outlineSimulations run through few phases, reaching full performance shortly, emulating and monitoring aperiodic traffic generated by nodes. In this paragraph we are going to take a snapshot on the basic working scheme in order to describe them in detail later.

FLow gEnErATor ArrAyAll flow generators are stored inside a protected STL (Standard Template Library) list variable called __gens, inside Nodes class. At the beginning of each simulation, the list is empty and, then, randomly populated by all those flow generators passing the admission test.


Pag. 4

schEduLATIon AT A gLAncEAs said before, Scheduler writes a file read by every component in the simulated network. The beacon file is used to assign to components their own turns to speak in; in particular, this special file assigns one or more slots to this elements:

• Polling Server: Some slots are reserved for this component in order to let it manage aperiodic flows. Note that Polling Server has a fixed number of slots that never changes during simulations. The total time reserved to Polling Server is referred to as: Cs.

• Nodes/Flow generators: Every flow generator admitted to the network has one slot where it can send an aperiodic flow notification.

• Free space/Contention phase: There might be some free (unassigned) slots where no one can speak, this space is tipically reserved for new nodes willing to join the network.

A detailed description of the scheduling file format and management will be performed in the next chapter.

sImuLATIon ordInAry runTImE (sImPLEsT cAsE) AT A gLAncEWhen a new simulation begins, Polling Server and Nodes syncronize on a common clock in order to emulate TDMA slotted time division. The main goal is ensuring nodes registration and aperiodic traffic to be managed by Polling Server. In order to let this model work, the system goes through these steps:

1. After components initialization, there are no flow generators in Nodes; meanwhile, Scheduler writes the beacon file specifying the initial schedulation (all slots available for new nodes to attach to the network).

2. After initialization finishes, Nodes and Polling Server interact in order to emulate aperiodic flow transmission and schedulation.

nEw nodE AccEPTAncE AT A gLAncESimulations are based on the possibility for a new node to attach to the network, in order to send its own aperiodic flows. This means that everytime a new node wants to join the network, the registration process has to be executed, in order to compute the response time and evaluate whether a feasible schedulation is possible. The overall process consists in these steps:

1. At runtime, Nodes, during a blank time slot (not owned by any already admitted flow generator), creates a new generator (allocating a FlowGenerator instance and adding it to __gens) and then sends to Admission Control its respective regitration message.

2. The registration message reaches Admission Control and carries important information about the node willing to join (like its relative deadline). Thus, Admission Control is able to perform the response time analisys in order to understand if a feasible schedulation is possible, considering the new node’s deadline.

3. If a feasible schedulation is found, the new flow generator is admitted among preexisting generators and Scheduler will receive a notification for rewriting the beacon file (in which a blank slot will be assigned to the new generator). On the other hand, if the attaching node cannot be scheduled because of a response time analisys failure, it is dropped from Nodes internal data structures and rejected by Admission Control (Scheduler will not even be called).


Pag. 5

Scheduling aperiodic flowsNodes and Polling Server timing synchronization, Scheduling file format, Aperiodic flow generation, Aperiodic flow management in Polling Server, New node attachment to the network, Queue overload phenomenon

Clock synchronization in Polling Server and NodesIn order to let the system simulate TDMA slotted access to the communication channel for sending/receiving flows, Polling Server and Nodes components implement an alorithm to be always aware of the same slots. This functionality will be referred to as: slot management.

Slot management is implemented by means of self-messages functionality available in OMNeT++. During initialization phase, Polling Server and Nodes send to themselves a self-message scheduled at the present time (no dealy); this bootstrap message is called Boot. When components receive their respective Boot messages, a slot initialization procedure is executed.

TdmA ImPLEmEnTATIon In dEPThIn our simulations, time is not considered like a continuous entity, we just focus on slices. This automatically allows us to prefer a discrete time model, based right on slots rather than handling a more complicated space. Thus, TDMA is modelled by means of an integer variable (embodied in a protected integer member called __slot) which always represents the present slot during every microcycle; this variable will also be referred to as: slot variable from now on.

Focusing on slots also implies the uselessness of considering a time space greater than the microcycle, which becomes our basic time macro-unit. For this reason, when components’ slot variable reaches the last slot value, it is reset to zero (representing the first slot in a new microcycle). An appropriate procedure checks, for each slot, whether the slot variable assumes its highest value (stored inside an OMNeT++ simulation variable), and thereby acts to control its growth. This routine will be referred to as slot management.

Managing slots through scheduling fileAs announced before, a file is used in order to let every component in the simulation know the present schedulation made by Scheduler (the only element able to write it). This file is simply formatted to reach the following goals:

• Defining those slots reserved to Polling Server to serve aperiodic flows through its internal queues.

• Defining, in a microcycle, the association between a slot and its owner (an admitted flow generator).

To act this way, the scheduling file keeps this formatting rules:

1. The scheduling file contains information for the present microcycle only, when a new microcycle begins the file must be overwritten if a new scheduling is about to take place (a new node attachment to the network, for instance).

2. The file contains a list of numbers separeted by a carriage return (line feed by adding the “\n” character).


Pag. 6

Every number represents the node identifier (flow generator ID); the association between the node and the owned slot is made through the position of the node ID in the list (an explanatory example is provided further on, in this paragraph). By doing so, we map the slot progressive number (or slot ID) on the position of the node ID in the file.

FILE sTrucTurEAs explained before, the schedulation file must provide two information regarding node/slot association and Polling Server slot reservation. For this reason the file uses a personal coding rule for reaching these objectives:

1. Every line of the file represents a slot progressive number (slot ID). So the first line is the first slot (slot ID = 0, because slot numbering is zero-based); the second line of the file is the second slot (slot ID = 1); the third line of the file is the third slot (slot ID = 2) and so on.

2. The number placed in each line represents the node ID to which the respective slot is assigned to. Given the presence of different components assignable to slots, in the file, assignments are made through the following scheme:

• When the slot is reserved for the beacon file to be read by Nodes, the respective line contains the special node id value -1000. This indicates that everyone, during this slot, must not speak, but just acquire data from the beacon.

• When the slot must be assigned to Polling Server, the respective line contains the special node id value -1.

• When the slot must be assigned to a flow generator in Nodes, the respective line contains the node ID value (which is an unsigned integer number, unique for every node).

• When the slot is unassigned (a free space for a future node to join the network), the respective line contains the special node id value -100.

Note that the number of lines in the file does never change, because the total number of slots in a microcycle is constant during the whole simulation.

TImELInE mAnAgEmEnTPolling Server and Nodes must syncronize clocks, as said before, in order to have the same time consciousness. The beacon file enstablishes how time must be assigned among Polling Server and flow generators, so they don’t crash trying to transmit in the same time slice.

That’s why these components in the network keep a timeline in order to store scheduling information, knowing, everytime, the slot number and its owner. Timeline is stored in Polling Server and Nodes as a protected class member, typed as an STL integer vector called __timeline. During the beginning of every microcycle, when slot is 0, the beacon is read and the timeline filled with the same values in the file; this approach let us simulate the real scenario where the beacon is broadcasted to all FNs.

Aperiodic flow generationEverytime a new node successfully register to the network, it will be able to speak, sending aperiodic flows,

1: -10002: -13: -14: 234655: 239876: 298577: 107468: -1009: -100

Example of a beacon file.


Pag. 7

starting from the next microcycle.

ProBABILIsTIc FLow gEnErATIonDuring a microcycle, Nodes questions the flow generator owning the present time slot, according to the beacon file written by Scheduler at the beginning of the microcycle, to get an aperiodic flow. Each flow generator implements an internal algorithm as a protected member function named gotApe(), which returns back, when called, a new aperiodic flow; this routine generates a one-shot flow with a certain probability distribution (uniform), so it is not sure that one node, when requested, will send something in its turn to speak.

All parameters regarding probabilistic flow generations are stored in simulation variables, and may vary from one simulation to another.

Scheduling flows in Polling Server and managing deferred flow transmissionPolling Server performs two activities:

1. Listening to flow generators for new aperiodic notifications, during the present microcycle.

2. Scheduling aperiodic flows, at the end of the present microcycle, and serving them in the next microcycle (during its reserved slots).

dEFErrEd TrAnsmIssIon modELOur simulations try to evidence schedulations’ feasibility through flows monitoring. One important aspect we want to observe is how efficiently the simulated network is able to schedule, without deadline misses, aperiodic flows in the worst case scenario.

When an aperiodic flow is transmitted by a flow generator, Polling Server will act performing operations as if it were in the worst case scenario.

real worst case: Considering the original Flexware architecture (and not the simulated/simplified one), when a new aperiodic flow is sent to Polling Server by Nodes, the worst situation occurs when the one-shot flow notification is generated by a node right an istant after its slot.

If such a case happens, the new notification cannot be sent to Polling Server until the next node’s slot (in a following microcycle). After waiting node’s next turn, the notification of an aperiodic flow is sent; another Polling Server period has to pass, so that the pending notification can be scheduled and eventually served.

InTErnAL QuEuEsPolling Server class has two important protected STL (C++ Standard Template Library) typed members, they represent two queues used for accepting aperiodic flow notifications and scheduling them through Deadline Monotonic algorithm:

Temporal diagram showing the real worst case scenario during an aperiodic flow transmission by Feexware Node 1.


Pag. 8

Schedulation provided by Scheduler through the beacon frame

fn4

fn1’s turn to speak

PS PS PS PS PS PSfn1 fn2 fn3 fn4 fn1 fn2 fn3 fn4 fn1 fn2 fn3B B B

fn1’s ape spawns here

fn1 waits its turn to speak again fn1’s sends its ape

PS schedules ape hereEmpty slot

• Waiting queue: This queue, called __wait, is an STL list of Flows (message type) member. It contains the incoming one-shot flow notifications generated by Nodes during the microcycle.

• Pending queue: This queue, called __pending, is an STL list of Flows (message type) member. It contains those flows to be scheduled and sent during the next microcycle. Deadline Monotonic aglorithm is applied to this queue.

simulated worst case: Our objective is always simulating the worst case scenario described before. In order to do that, a double schedulation queues scheme is used in Polling Server, as announced. When a new aperiodic flow notification is sent, it is stored in the waiting queue (differing phase); during the next microcycle, in the node’s slot, the flow will be moved from the waiting queue to the pending queue (schedulation phase) using Deadline Monotonic. The pending queue will be popped out during next Polling Server reserved slots (serving phase) according to server capacity.

It is important to consider that when Admission Control admits a flow generator, the response time analysis is performed right to verify whether the new node, with its constant deadline for aperiodic messages, can be scheduled. If so, every time that a new flow is sent by that node, it is suppoed to be scheduled and served without occurring in a deadline miss.

In practice, such a situation does not occur always due to admitted nodes having a shorter relative deadline than others.

schEduLATIon In dEPThLet us focus on a microcycle and let us consider the beginning of a new one. We are now going to outline how a new flow is scheduled and served during microcycles; to get a clear and explainatory description, the previous nomenclature is used.

Differing new flows: After Nodes reads the beacon file (whenever slot is 0), a new schedulation takes place and, while time slots occur, some flow generators may send an aperiodic flow notification. During this phase (we could call it: ongoing microcycle) Polling Server simply waits for new one-shot traffic arrival; when a new aperiodic notification is sent by a node, Polling Server puts it into the waiting queue (no sorting algorithm is performed), which is just a mere FIFO bucket where dropping new notifications. Furthermore, the waiting queue cannot contain two notifications belonging to the same node during a microcycle, because a node can’t send a new aperiodic notification until its worst case response time (evaluated by the Admission Control) has passed from the previous generation.

Scheduling flows: In order to simulate the worst case scenario, after the new flow notification arrives and is put in the waiting queue, the present microcycle ends and a new new one takes place. Everytime that a slot owned by a flow generator is reached, Polling Server (according to the timeline) looks for a flow sent by it in the waiting queue; if a notification is found, it is moved to the pending queue, using Deadline Monotonic sorting algorithm.

Temporal diagram showing the simulated worst case scenario during an aperiodic flow transmission by Flow Generator 1.


Pag. 9

Schedulation provided by Scheduler through the beacon �le

fg4

fg1’s turn to speak. An ape noti�ca-tion is generated with a certain

probability. It is received by PS and stored in the waiting queue

PS PS PS PS PS PSfg1 fg2 fg3 fg4 fg1 fg2 fg3 fg4 fg1 fg2 fg3B B B

fg1 waits its turn to speak again

PS �nds the fg1’s noti�ca-tion in the waiting queue

and moves it in the pending queue using DM

PS schedules ape hereApe is dropped from pending and served

The waiting queue is the way to simulate the worst case scenario as explained before; thanks to it, every flow notification is effectively scheduled after one microcycle and served after another one.

Serving flows: Polling Server can serve flows inside the pending queue by popping them in each slot owned by it (for a number of slots equal to the server computation time, constant during each simulation). This process do not necessarlly lead to the pending queue emptying so that, at the end of the Polling Server slots, there still might be pending aperiodic flows to be served in the next microcycles.

Please mind that whether a notification with lower relative deadline than a previously scheduled one is moved from the waiting queue to the pending queue, according to Deadline Monotonic algorithm, it will be the first to be served, deferring other notifications to be managed during the following microcycles. This might cause the system to experience deadline misses.

Managing a new node joining the networkAs announced in the previous chapter, our simulations are able to manage with the entrance of new flow generators in the network.

cEnTrALIzEd conTroL By nodEsTo simplify the network, the creation of new flow generators is fully managed by Nodes. During the beginning of each microcycle, Nodes reads the beacon file and builds its timeline so that it knows where unassigned slots are located. Thus, during each empty slot, Nodes creates a new flow generator with a probability threshold set in the SPAWN_FG_THR simulation variable. If a new generator is instantiated, Nodes sends to Admission Control a registration message through the getReg() Flow class’ member function. Mind that, if no empty slot is found, no new nodes are created.

response time analysis: When the registration message arrives (Flow typed message), its data is stored by Admission Control in order to execute the response time analysis (RTA). RTA for a specific flow generator ensures that a feasible schedulation for that node is possible, considering all other already scheduled generators having a lower relative deadline.

This implies the possibility to retrieve data from the already admitted nodes; for this reason, Admission Control keeps a list (class member called __flows) of the accepted flow generators to be queried everytime that RTA has to be performed.

Admission/rejection: A new flow generator can be admitted only if its worst case response time (WCRT) is lower than its relative deadline. Given that WCRT considers the present schedulation, the new node is attached only if a feasible schedulation exists, examinating all generators having a lower relative deadline. That’s why an outstanding probability that the new node might be rejected must be considered.

When a new node is admitted, it is inserted in the Admission Control’s list and its data is sent to Scheduler, which writes the beacon file assigning a slot to the joining flow generator. If RTA returns a value higher than the relative deadline, the generator is rejected. Nodes must be also notified about the expelled node (still stored in the __gens list variable); so, every microcycle, Nodes’ internal list of generators is cleared from those ones who are not scheduled in the beacon file (if a node is not admitted, it will not appear in the file).


Pag. 10

Understanding the Queue Overload phenomenonWe are now going to simulate various scenarios; before doing that it is important to point out a singular phenomenon that occurs during simulations of those scenarios aiming to test the system with a high stress factor, acting, in particular, on the traffic intensity and uniformity (aperiodic flow generation probabilities). More specifically we experience this problem when all flow generators have almost the same probability to transmit.

In such simulations, Polling Server is requested to schedule a lot of flows, inserting and moving aperiodic notifications in the waiting and in the pending queue. The pending queue sorts its flows using Deadline Monotonic algorithm which puts those flows having a higher relative deadline in the bottom of the data structure. When we handle a large amount of traffic, the pending queue easily increases its size without a proper growth management policy; a schedullation anomaly arises when traffic is particularly intense.

In fact, all flows having the highest relative deadline are always placed in the bottom of the queue, while all other flows will be served before them; meanwhile other aperiodic flows having a lower relative deadline will always be inserted in the pending queue (as slots pass by), causing the same long deadline flows mentioned before stay in the bottom of the pending queue. This situation, when aperiodic flow generation probabilities reach a high level (about 0.45), tends to unchange, generating an incrementing residue of flows that will never be served.

This anomaly is an intrinsic characteristic of the simulated network; it is an anomaly, not an error nor an architecture imperfection. It is possible to recognize a reasonable explaination of what happens considering that deadline monotonic (used as the primary schedulation algorithm) is designed for aperiodic messages; the Queue Overload phenomenon occurs when we lead our aperiodic handling system to behave like a sporadic or even periodic one, without changing the algorithm (which remains aperiodic). This mismatching causes the Queue overload to occur.

No growth management policy is implemented for both waiting and pending queue, because it is not a purpose in aur simulations; moreover, this allows us to monitor system performance lowering in order to identify the exact aperiodic generation probability level that leads to this problem.


Pag. 11

Simulation S-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

rEsuLTs ABouT FLow gEnErATorsDuring simulation, Admission Control’s activity about registration request management is summarized below:

Total requests Admitted rejected62 15 47

Each flow generator reported the following statistics:

Tot d r wcrT Pr{TX} mean delay mean r.T. σ R.T.Fg4010 319 40 228 40 0.84 15 25 0Fg13869 322 40 314 40 0.84 16.6 23.4 0.49Fg5124 315 42 17 40 0.81 12.05 29.95 0.67Fg19312 330 42 103 40 0.82 13.68 26.32 0.85Fg4588 323 42 251 40 0.85 16.14 25.86 0.98Fg23067 315 44 10 40 0.81 8.61 35.39 2.56Fg58174 320 44 166 40 0.83 14.01 29.98 4.86Fg25168 330 45 8 40 0.86 3.57 41.42 7.42Fg58295 315 45 16 40 0.80 6.21 38.78 8.99Fg51543 318 45 38 40 0.83 6.34 38.65 9.74Fg57359 339 46 12 40 0.88 -322.11 368.11 229.65Fg46797 326 51 9 40 0.83 -448.6 499.6 672.39Fg12491 327 51 11 40 0.82 -803.2 854.2 1420.69Fg65405 328 52 7 40 0.87 -7.67 59.67 0.47

Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea Tino

Pag. 12

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

Tot d r wcrT Pr{TX} mean delay mean r.T. σ R.T.Fg16251 314 54 6 40 0.80 2.5 51.5 10.5

The table shows, for those generators having a high relative deadline, very high negative delay values (and consequently high standard deviations). Such a situation occurs because many flows are never checked by the Polling Server when popping the pending queue, given the presence of other flows having a lower relative deadline. Please note that data starting from FG57359’s row might be inconsistent because of the Queue Overload phenomenon.

rEsuLTs ABouT APErIodIc FLowsPolling Server statistics regarding aperiodic flows management are shown below:

Total received flows served deadline misses served ratio4841 2947 611 0.61

As it is possible to see, there is a residual number of flows that are not present in data shown in the previous table: 4841 - 2947 - 611 is not zero! This happens because, consulting queue log files, a large amount of unserved flows remain in the pending queue at the end of the simulation (Queue Overload phenomenon). In particular, data shown in the generators’ statistics table is not reliable for those generators having relative deadline greater than 45, because they have never been checked by Polling Server when popping the pending queue. Taking a look at queue log file, it is possible to notice that, during the last microcycle, the pending queue contains several expired flows created by FG40797, FG12491, FG65405 and FG16251.

The pending queue never reduces in time because this scenario is the worst possible regarding server capacity and trasmission behavior, leading the system to manage quasi-periodic traffic without a proper off-line schedulation.

Final considerationsAs said before, this scenario shows that aperiodic real time traffic turns into quasi-periodic traffic and that handling it with an unproper algorithm like Deadline Monotonic (not designed for such situations) does not lead to a suitable result. The same simulation has been run setting lower transmission probabilties (ranging from 0.1 to 0.3) and, in this case, performance gets better and the pending queue reduces its size properly.

This simulation is, obviously, the extreme case, when everything goes wrong. It is a valid simulation because it allows us to set up an upper bound in our simulation space. In the next scenarios we will act on aperiodic thresholds in order to make the system get near to this case, and monitor how the network behaves in very bad conditions.

Given the importance of this scenario, that we will use to make several comparisons from now on, we are going to use refer to it as Worst case scenario.


Pag. 13

Simulation S-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



As it is possible to notice, there is an empty slot at the end of the simulation; this happens because of the scenario settings, making more difficult for a new node to join the network.

Each flow generator reported the following statistics:

Tot d r wcrT Pr{TX} mean delay mean r.T. σ R.T.Fg12295 111 40 10 40 0.17 7 33 0Fg1264 135 40 20 40 0.23 9.78 30.21 0.41Fg1186 129 40 41 40 0.24 13.66 26.34 0.55Fg54179 72 40 61 40 0.12 14.5 25.5 0.73Fg65516 64 40 251 40 0.11 15.47 24.53 0.68Fg62592 83 41 8 40 0.15 5.41 35.59 0.64Fg54320 55 42 35 40 0.10 12.13 29.87 0.74Fg2845 101 42 38 40 0.16 13.93 28.07 0.94Fg53834 83 43 36 40 0.12 13.64 29.36 2.37Fg59414 99 44 6 40 0.13 5.97 38.03 1Fg15582 113 44 15 40 0.21 11.59 32.40 2.20Fg2787 82 45 12 40 0.15 11.66 33.34 1Fg56230 148 46 9 40 0.29 10.06 35.94 2.99


Pag. 14

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

Tot d r wcrT Pr{TX} mean delay mean r.T. σ R.T.Fg38907 68 48 7 40 0.11 9.23 38.76 4.32

The table shows, for each generator, a general condition that we could assume to be normal and generally ideal: mean delays are all positive and mean response times do not cross the floor of 39 slots; in this conditions the system probably experiences a low number of deadline misses.



As it is possible to see, served flow ratio is high despite relative deadlines are very close to each other; Deadline Monotonic is able to schedule aperiodic flows in this conditions. The system experiences few deadline misses (after simulation time reaches value 9.000) due to those generators having higher probability to transmit.

Final considerationsThis is the opposite scenario to the one proposed in the first simulation: we can see the results of a normal and mean configuration. In this case, flow generators will create aperiodic flows with a very small probability, avoiding to overload the pending queue. As said before, this is another limit case where everything goes well (experiencing a 0.1 deadline miss ratio), and, in the same way described for the previous simulation, this scenario, dually, defines a lower bound in our simulation space.

nEXT sImuLATIonsNext scenarios will provide a configuration variety based on the number of slots in a microcycle. Our aim is to set up the network in three different conditions:

1. Small microcycle: There are few slots reserved for the entire microcycle, the number of flow generators is small and Polling Server should experience a low traffic intensity.

2. Medium microcycle: The number of slots in a microcycle is set to a medium range value (a mean real case); the number of flow generators is contained and the number of flows managed by Polling Server is significant but not critical.

3. Large microcycle: The microcycle is composed by many slots offering a place for many flow generators. The traffic intensity is high and Polling Server is stressed by a critical situation.

During simulations of these scenarios, deadlines will be set to vary inside a contained constant range while, for each scenario, three sub-scenarios will be simulated by acting on aperiodic threshold. By doing so, it is possible to monitor, how every scenario responds when lead to a critical condition.

This approach ideally leads us from the S-298993 to the S-179462 scenario, letting us analyze the network conditions moving from the best to the worst case.


Pag. 15

Simulation S-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 S-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





As it is possible to see, having a high ratio is due to deadline generation policy: deadlines range from 20 to 40 slots, a high interval.

Considerations about scenarioThe first attempt of simulating this scenario was conducted using a lower deadline interval between 20 and 30 slots; results reported a lower served ratio (0.88) and an empty slot could not be filled by Admission Control at the end of the simulation. Setting a deadline upper bound generation to 40 let us reach a better admission policy other than a better schedulation behavior as said before.


Pag. 16

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

Simulating scenario S-297555:s02Simulation 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





Missing flows are still in waiting and pending queue at the end of the simulation.

Considerations about scenarioAs it is possible to notice, performance is lower than the previous scnario due to a higher aperiodic flow generation probability. A general system degradation is experienced (and so it will be for the following simulations) when flow generators have quite the same probability to transmit aperiodic flows.

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



Pag. 17

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min


0.44 0.46


20 slots 40 slots


1.0





System starts experiencing the phenomenon evaluated in the S-298993 simulation (worst case); Polling Server is not able to serve many flows generated by those nodes having the highest deadlines.

Considerations about scenarioIn this scenario we could experience a singular case. During simulation time Polling Server is able to manage flows efficently until Admission Control let the last node join the network; this node has the shortest relative deadline (20), causing Deadline Monotonic to schedule its flows before every other. From this time on, system starts experiencing a general performance lowering, according to the worst case scenario simulated before.

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



0.64 0.66


20 slots 40 slots


Pag. 18

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





Polling Server schedulation performance lowers further regarding the previous scenario; in fact it is possible to experience an incrementing flow residue inside the pending queue (for those generators having the highest deadline) right at 0.8% of the total simulation time.

Considerations about scenarioThis scenario let us evaluate how scheduling performance conditions lowers when traffic intensifies.

Simulating scenario S-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



rEsuLTs ABouT APErIodIc FLows


Pag. 19

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

Polling Server statistics regarding aperiodic flows management are shown below:


We have 1535 never served aperiodic flow notifications in the pending queue concordently with the Queue Overload phenomenon.

Considerations about scenarioComparing the worst case scenario’s served ratio, our one is even worse; this happens because S-298993 scenario works using less restrictive settings.

Final considerations about overall simulationThe chart shows how fastly the system performance lowers down dramatically as aperiodic flow generation threshold increases (mind that all flow generators have almost the same probability to send an aperiodic notification, concordently with the aperiodic generation threshold interval). It is remarkable how every node, starting from those ones having the highest relative deadline, as generation threshold increases, experiences the Queue Overload phenomenon, so that, at a certain point, it is also useless to report its mean response time (because it is not reliable or it just does not figure in log files).

This simulation reports a bad overall class of scenarios because of the number of slots reserved to the Polling Server.

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

10

20

30

40

50

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 = 8D = 33, r = 5D = 36, r = 6

Simulation S-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 S-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 ratio3385 3383 0 1

As it is possible to notice, this scenario represents an ideal condition; no deadline misses are experienced and all flows are managed by Polling Server. Nothing relevant to report. Served ratio is one because there are two elements in the waiting queue ready to be scheduled.

Considerations about scenarioThere is nothing much to say about this scenario; everything goes fine and there are no problems or special events to report.


Pag. 21

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

Simulating scenario S-446696:s02Simulation 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





Compared to the previous scenario, the network starts experiencing a little number of dealine misses, non significant as served ratio reports; furthermore, we can notice an increment less than 50% in the total number of processed flows.

Considerations about scenarioFor this scenario too, we have nothing relevant to say, except about a slight lowering of system performance, a sure predictable result.

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



Pag. 22

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min


0.44 0.46


40 slots 80 slots


1.0





Even in this conditions, the pending queue is consistent and its growth behaves normally; Deadline Monotonic responds well.

Considerations about scenarioCompared to the previous class of scenarios (S-297555), we experience a better simulation trend. In fact, it is possible to notice that, at the third scenario, the Queue Overload phenomenon doesn’t occur at all. This means that a 20 slots large microcycle with deadlines set proportionally (maintaining deadline limit to 4 times the microcycle length) is better than a 10 slots one.

Simulating scenario S-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


Pag. 23

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





A 25% increment of the total received flows is experienced by the system; furthermore, the schedulation anomaly we identified as Queue Overload occurs. More specifically, the pending queue reports a flow residue of more than 600 aperiodic notifications never served during the entire simulation.

Considerations about scenarioThis scenario shows how the Queue Overload phenomenon is experienced by this network. Making comparisons with the previous simulation (S-297555), the schedulation anomaly occurs later and with a smoother increasing factor.

Simulating scenario S-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




Pag. 24

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min



As predicted, an total managed flow increase is experienced and a lesser ratio can be noticed; however it is remarkable that the number of deadline misses has grown by 2 elements only. This situation is due to the occuring of the Queue Overload phenomenon which causes amost 6000 flows to stagnate inside the pending queue.

Considerations about scenarioSystem performance lowers dramatically compared to the previous scenario, but we must always consider that this result is always better than the one experienced in the fifth scenario of the first simulation (S-297555), where an even much greater number of unmanaged flows is reported.

Final considerations about overall simulationThis simulation wants to test the system providing information about its robustness to traffic intensification. Making comparisons with the previous class of scenarions (S-297555), we can see that our network is able to better tolerate a major amount of aperiodic traffic. A less number of deadline misses is experienced as well for the served flow ratio. More specifically, it is remarkable how the schedulation algorithm is able to maintain a good trend in performance and flow management.

Looking at the chart showing the mean response time reported by the most significant generators, it is possible to notice that these scenarios define a better condition for the overall system. In fact, all flow generators, experience a response time generally positioned at the same level. Of course, the Queue Overload phenomenon occurs but it is not as significant as before.

Generally, we can state that a microcycle set to 20 slots allows the network to better manage the schedulation

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

20

30

40

50

t=0.8t=0.65t=0,45t=0.35t=0,2

D = 40, r = 19D = 48, r = 20

D = 50, r = 14

D = 80, r = 13

D = 45, r = 10D = 58, r = 12

D = 48, r = 7

D = 64, r = 9

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

anomaly. This is sure a better result if compared to the general trend experienced in the previos simulation even because the system does not differ in other parameters given that the microcycle has been enlarged proportionally, so that the server capacity and the simulation overall time have been consequently incremented too.


Pag. 26

Simulation S-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 S-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




Total received flows served deadline misses served ratio8936 8925 0 1

No deadline misses are experienced and all flows are managed by Polling Server. Nothing relevant to report. Served ratio is one because there are some elements in the waiting queue not yet scheduled.

Simulating scenario S-896322:s02Simulation information and resultsBy incrementing the aperiodic flow generation threshold, we want to test the system robustness to a general traffic intensification.


Pag. 27

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min



0.34 0.36


100 slots 200 slots


1.0





It is possible to experience an irrilevant number of deadline misses and a minimal lowering of the served ratio.

Simulating scenario S-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


100 slots 200 slots


1.0



Pag. 28

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




As we can see, performance lowering is represented by a significant increment of the number of deadline misses. However, the served ratio does not experience a remarkable variation.

Considerations about scenarioThis scenario is placed in the central point of the simulation space, it is interesting to point out how the number of deadline misses is almost the mean between the ones experienced in the previous classes of scenarios.

Simulating scenario S-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





As aperiodic flow generation threshold increases, the number of processed flows grows significantly. In this


Pag. 29

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

case, we experience also a remarkable higher value of deadline misses. Furthermore the Queue Overload phenomenon is experienced too, in fact, the pending queue counts more than 2000 notifications.

Considerations about scenarioIn this scenario, we can see how the served ratio lowers to a still good level; this situation is not experienced during the other simulations; although this might be considered a good factor, we must consider the presence of the Queue Overload which pollutes our statistical data.

Simulating scenario S-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.



As shown in the table, we experience a significant lowering of performance. Although the number of deadline misses is lower regarding the previous scenario, this information, unfortunately, is highly corrupted by the Queue Overload phenomenon. In fact, opening the log file showing the queue content, we find that flow residue in the pending queue is about 4600.

Considerations about scenario


Pag. 30

0,2

0,4

0,6

0,8

1,0

T3 T1max

T1min

As expected, the worst case scenario occurs and the Queue Overload phenomenon takes place.

Final considerations about overall simulationIt is useful to make comparisons between this class of scenarios and the last one (S-297555), in particular, when summarizing the simulation activity using the flow generators’ mean response time chart.

As it is possible to notice, both charts show a generic constant trend; although many similarities occur, there are little variations showing that this simulation provides a better configuration from the point of view of the response time, meaning that this configuration let the system maintains on a much more stable condition.

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

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 = 15D = 147, r = 23D = 111, r = 14D = 116, r = 17

D = 106, r = 29

D = 129, r = 26

D = 195, r = 35

Summarizing simulationssimulations: s-297555, s-446696, s-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 consider, in the second simulation, an attempt of reaching a constant level, while the other

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

S-297555

0,4

0,6

0,8

1,0

t = 0.8t = 0.65t = 0.45t = 0.35t = 0.2

S-446696

S-896332

S-297555

0

200

400

600

800

1000

1200

t = 0.8t = 0.65t = 0.45t = 0.35t = 0.2

S-446696

S-896332

simulations experience considerable variations. Please note that the values reported for the last scenario (for each simulation) are strongly polluted by the Queue Overload phenomenon that makes impossible to correctly collect statistical data. Note also that the final variations in the curves can measure the pollutioning level experienced by every simulation.


Pag. 33

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 - AppendixesDavide 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

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