Implementation of aDeadlineMonotonicbased algorithm foraperiodic traffic schedulingon a two-tired networkarchitectureDavid...
Architecture outlineIntroduction to our project, Flexware architecture overview, overallcomponents and parts of interestPr...
Simulated architectureComponents and simulated parts, Dynamics and data flowsComponents in simulationThe simulated network...
registered nodes. Scheduler ensures scheduling management (through TDMA slot/node associations),letting everyone in the ne...
Schedulation at a glanceAs said before, Scheduler writes a file read by every component in the simulated network. The beac...
Scheduling aperiodic flowsNodes and Polling Server timing synchronization, Scheduling file format,Aperiodic flow generatio...
Every number represents the node identifier (flow generator ID); the association between the node andthe owned slot is mad...
starting from the next microcycle.Probabilistic flow generationDuring a microcycle, Nodes questions the flow generator own...
•	 Waiting queue: This queue, called __wait, is an STL list of Flows (message type) member. It contains theincoming one-sh...
The waiting queue is the way to simulate the worst case scenario as explained before; thanks to it, every flownotification...
Understanding the Queue Overload phenomenonWe are now going to simulate various scenarios; before doing that it is importa...
Simulation S-298993Simulation main goal: Deadline Monotonic stressing attempt evaluating QueueOverload phenomenonSimulatio...
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.5The table shows, for those generators...
Simulation S-179462Simulation main goal: Low variation of relative deadlineSimulation duration: 15.000 simulation time uni...
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.32The table shows, for each generator,...
Simulation S-297555Simulation main goal: Low number of slots, same probability of aperiodicnotification transmissionSimula...
Simulating scenario S-297555:s02Simulation information and resultsIn this simulation we increment deadline thresholds in o...
Min (nominal) value Max valueSlot number 10 slotsAperiodic generationthreshold (T1)0.44 0.46Server capacity 2 slotsAperiod...
Min (nominal) value Max valueFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admis...
Polling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses...
Simulation S-446696Simulation main goal: Medium number of slots, same probability of aperiodicnotification transmissionSim...
Simulating scenario S-446696:s02Simulation information and resultsIn this simulation, we will take the aperiodic generatio...
Min (nominal) value Max valueSlot number 20 slotsAperiodic generationthreshold (T1)0.44 0.46Server capacity 5 slotsAperiod...
Min (nominal) value Max valueFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admis...
Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received...
anomaly. This is sure a better result if compared to the general trend experienced in the previos simulationeven because t...
Simulation S-896332Simulation main goal: High number of slots, same probability of aperiodicnotification transmissionSimul...
Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 50 s...
Total requests Admitted Rejected56 38 18Results about aperiodic flowsPolling Server statistics regarding aperiodic flows m...
case, we experience also a remarkable higher value of deadline misses. Furthermore the Queue Overloadphenomenon is experie...
As expected, the worst case scenario occurs and the Queue Overload phenomenon takes place.Final considerations about overa...
Summarizing simulationsSimulations: S-297555, S-446696, S-896322Summarizing served ratioConsidering the three simulations ...
simulations experience considerable variations. Please note that the values reported for the last scenario (foreach simula...
Log files and logging rulesIn order to produce statistics about a particular simulation and show its data for analysis and...
4.	 Queues log file (example: qlog_001.log): This file is written by Polling Server and provides a way forlooking inside t...
Simulation reports’ glossaryThe simulations section of this document shows several data structures, tables and charts in o...
Upcoming SlideShare
Loading in …5
×

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

682 views

Published on

Aperiodic traffic scheduling on networks. Real Time.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
682
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. Implementation of aDeadlineMonotonicbased algorithm foraperiodic traffic schedulingon a two-tired networkarchitectureDavide Giuseppe MonacoAndrea TinoUniversità degli Studi di CataniaFacoltà di Ingegneria Informatica2010Real Time SystemsEnd course project reportProf. L. LoBelloEng. E. ToscanoSupervisorAssistant supervisor
  2. 2. Architecture outlineIntroduction to our project, Flexware architecture overview, overallcomponents and parts of interestProject and main objectivesOur project consists in designing and simulating a simpified two tired network (based on the Flexwarearchitecture), in order to produce statistics about aperiodic real time traffic handled by certain nodes. Bydoing so, our most important goal is achieving knowledge about how efficiently the entire system can managealarms and one-shot real time traffic, respecting time constraints.To simulate such a network, the Eclipse based Omnet++ environment has been used, building and simulatingnodes 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 industrialpurposes; for this reason, our project is bound to some special nodes and components that has been createdin our simulations.Two-tired schemeFlexware network’s goals are mostly focused on allowing real time traffic transmission on wireless physicallayer; given the large amount of problems concerning time constraints, a pure wireless connection cannotguarantee efficent trasmission of such a data stream type; thus, an hybrid approach is needed, providinga 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 isimplementing a Dealine Monotinic scheduling algorithm on the Polling Server of FAPs, in order to manageaperiodic 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 sendingtheir own flows. This time sharing mechanism is located in the middleware level, FCs are responsible formanaging node traffic schedulation.Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 2
  3. 3. Simulated architectureComponents and simulated parts, Dynamics and data flowsComponents in simulationThe simulated network works using four main components:• Nodes: This component in connected to Polling Server and Admission Control, it contains a variablenumber of Nodes (for each simulation) able to generate aperiodic traffic to be scheduled. It is possible tofigure 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 DeadlineMonotonic sheduling algorithm is built and works inside this component.• Admission Control: This component is connected to Nodes for incoming flows and to Scheduler foroutgoing traffic. Admission Control ensures node registration in order to let Polling Server know how manynodes (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 beattached to the network, knowing its traffic information.• Scheduler: This component is connected to Admission Control only, accepting its information regardingReal Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 3Admission Control (AC)Di Ci FNiAperiodic flow dataScheduler (SCHED)t1 t2 tit3 ... ... tnBeacon fileFlowGeneratorFN1FlowGeneratorFN2FlowGeneratorFNiFlowGeneratorFNnPolling Server (PS)fn1 fn2 fn3 ... fni ... fnnfnj ... fn(j+k) ... fnmWaiting queuePending queueThis diagram shows the simulated network’s architecture. The lowest level is represented by Nodes (all flow generators are implicitilycontained inside a component called Nodes, not shown here), the Flexware middleware is represented by PS, SCHED and AC (allenbodied inside the same virtual component, the FAP, not modeled inside the simulated network). Shown connections match the onesinside the NED file of the simulated network. Furthermore, delayed channels are applied to Nodes/PS connection only.
  4. 4. 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 isread by Polling Server and Nodes, and it is written by Scheduler.No shared resource mutual exclusive access algorithm must be taken into consideration for thebeacon file, given that read and write operations are executed in different time slices. We will use theterms: 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 betransmitted from Nodes to Polling Server, we use a personal message type called Flow. Thus, our simulationsuse two message types:• Flow type: Created through msg OMNeT++ functionality, this message stores the most importantinformation 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 bootstrapmessages for clock initialization).Flow generatorsFlow generators represent a simplified way to emulate all nodes in the network. One generator is responsiblefor creating aperiodic real time traffic to be handled.All flows produced by a generator have the same relative deadline; this is a very important hypothesiswhen dealing with response time analysis during admission test.Simulation dynamics outlineSimulations run through few phases, reaching full performance shortly, emulating and monitoring aperiodictraffic generated by nodes. In this paragraph we are going to take a snapshot on the basic working scheme inorder 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 allthose flow generators passing the admission test.Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 4
  5. 5. Schedulation at a glanceAs said before, Scheduler writes a file read by every component in the simulated network. The beacon file isused to assign to components their own turns to speak in; in particular, this special file assigns one or moreslots to this elements:• Polling Server: Some slots are reserved for this component in order to let it manage aperiodic flows. Notethat Polling Server has a fixed number of slots that never changes during simulations. The total timereserved 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 anaperiodic flow notification.• Free space/Contention phase: There might be some free (unassigned) slots where no one can speak, thisspace 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 emulateTDMA slotted time division. The main goal is ensuring nodes registration and aperiodic traffic to be managedby 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 thebeacon 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 flowtransmission 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 ownaperiodic flows. This means that everytime a new node wants to join the network, the registration processhas to be executed, in order to compute the response time and evaluate whether a feasible schedulation ispossible. 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 anew generator (allocating a FlowGenerator instance and adding it to __gens) and then sends to AdmissionControl its respective regitration message.2. The registration message reaches Admission Control and carries important information about the nodewilling to join (like its relative deadline). Thus, Admission Control is able to perform the response timeanalisys 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 andScheduler will receive a notification for rewriting the beacon file (in which a blank slot will be assigned tothe new generator). On the other hand, if the attaching node cannot be scheduled because of a responsetime analisys failure, it is dropped from Nodes internal data structures and rejected by Admission Control(Scheduler will not even be called).Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 5
  6. 6. Scheduling aperiodic flowsNodes and Polling Server timing synchronization, Scheduling file format,Aperiodic flow generation, Aperiodic flow management in Polling Server, Newnode attachment to the network, Queue overload phenomenonClock synchronization in Polling Server and NodesIn order to let the system simulate TDMA slotted access to the communication channel for sending/receivingflows, 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++. Duringinitialization phase, Polling Server and Nodes send to themselves a self-message scheduled at the presenttime (no dealy); this bootstrap message is called Boot. When components receive their respective Bootmessages, 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 automaticallyallows 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 toas: slot variable from now on.Focusing on slots also implies the uselessness of considering a time space greater than the microcycle, whichbecomes our basic time macro-unit. For this reason, when components’ slot variable reaches the last slotvalue, 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++ simulationvariable), 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 presentschedulation made by Scheduler (the only element able to write it). This file is simply formatted to reach thefollowing 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 beginsthe file must be overwritten if a new scheduling is about to take place (a new node attachment to thenetwork, for instance).2. The file contains a list of numbers separeted by a carriage return (line feed by adding the “n” character).Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 6
  7. 7. Every number represents the node identifier (flow generator ID); the association between the node andthe owned slot is made through the position of the node ID in the list (an explanatory example is providedfurther on, in this paragraph). By doing so, we map the slot progressive number (or slot ID) on the positionof 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 apersonal coding rule for reaching these objectives:1. Every line of the file represents a slot progressive number (slot ID). So the first lineis the first slot (slot ID = 0, because slot numbering is zero-based); the second line ofthe 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 slotis assigned to. Given the presence of different components assignable to slots, in thefile, 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 thespecial node id value -1000. This indicates that everyone, during this slot, must not speak, but justacquire data from the beacon.• When the slot must be assigned to Polling Server, the respective line contains the special node idvalue -1.• When the slot must be assigned to a flow generator in Nodes, the respective line contains the node IDvalue (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 linecontains 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 amicrocycle is constant during the whole simulation.Timeline managementPolling Server and Nodes must syncronize clocks, as said before, in order to have the same timeconsciousness. The beacon file enstablishes how time must be assigned among Polling Server and flowgenerators, 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 classmember, typed as an STL integer vector called __timeline. During the beginning of every microcycle, when slotis 0, the beacon is read and the timeline filled with the same values in the file; this approach let us simulate thereal 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: -100Example of abeacon file.Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 7
  8. 8. starting from the next microcycle.Probabilistic flow generationDuring a microcycle, Nodes questions the flow generator owning the present time slot, according to thebeacon file written by Scheduler at the beginning of the microcycle, to get an aperiodic flow. Each flowgenerator implements an internal algorithm as a protected member function named gotApe(), which returnsback, when called, a new aperiodic flow; this routine generates a one-shot flow with a certain probabilitydistribution (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 fromone simulation to another.Scheduling flows in Polling Server and managingdeferred 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 aspectwe 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 performingoperations as if it were in the worst case scenario.Real worst case: Considering the original Flexware architecture (and not the simulated/simplified one), whena new aperiodic flow is sent to Polling Server by Nodes, the worst situation occurs when the one-shot flownotification 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 (ina following microcycle). After waiting node’s next turn, the notification of an aperiodic flow is sent; anotherPolling 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, theyrepresent two queues used for accepting aperiodic flow notifications and scheduling them through DeadlineMonotonic algorithm:Temporal diagram showing the real worst case scenario during an aperiodic flow transmission by Feexware Node 1.Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 8Schedulation provided by Scheduler through the beacon framefn4fn1’s turn tospeakPS PS PS PS PS PSfn1 fn2 fn3 fn4 fn1 fn2 fn3 fn4 fn1 fn2 fn3B B Bfn1’s apespawns herefn1 waits its turn to speak again fn1’s sends itsapePS schedules ape hereEmpty slot
  9. 9. • Waiting queue: This queue, called __wait, is an STL list of Flows (message type) member. It contains theincoming 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 containsthose flows to be scheduled and sent during the next microcycle. Deadline Monotonic aglorithm is appliedto this queue.Simulated worst case: Our objective is always simulating the worst case scenario described before. Inorder to do that, a double schedulation queues scheme is used in Polling Server, as announced. When a newaperiodic 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 timeanalysis is performed right to verify whether the new node, with its constant deadline for aperiodicmessages, can be scheduled. If so, every time that a new flow is sent by that node, it is suppoed to bescheduled and served without occurring in a deadline miss.In practice, such a situation does not occur always due to admitted nodes having a shorter relativedeadline 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 outlinehow a new flow is scheduled and served during microcycles; to get a clear and explainatory description, theprevious nomenclature is used.Differing new flows: After Nodes reads the beacon file (whenever slot is 0), a new schedulation takes placeand, 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 newaperiodic notification is sent by a node, Polling Server puts it into the waiting queue (no sorting algorithm isperformed), which is just a mere FIFO bucket where dropping new notifications. Furthermore, the waitingqueue cannot contain two notifications belonging to the same node during a microcycle, because a node can’tsend a new aperiodic notification until its worst case response time (evaluated by the Admission Control) haspassed from the previous generation.Scheduling flows: In order to simulate the worst case scenario, after the new flow notification arrives andis put in the waiting queue, the present microcycle ends and a new new one takes place. Everytime that aslot owned by a flow generator is reached, Polling Server (according to the timeline) looks for a flow sent byit in the waiting queue; if a notification is found, it is moved to the pending queue, using Deadline Monotonicsorting algorithm.Temporal diagram showing the simulated worst case scenario during an aperiodic flow transmission by Flow Generator 1.Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 9Schedulation provided by Scheduler through the beacon filefg4fg1’s turn to speak. An ape notifica-tion is generated with a certainprobability. It is received by PS andstored in the waiting queuePS PS PS PS PS PSfg1 fg2 fg3 fg4 fg1 fg2 fg3 fg4 fg1 fg2 fg3B B Bfg1 waits its turn to speak againPS finds the fg1’s notifica-tion in the waiting queueand moves it in thepending queue using DMPS schedules ape hereApe is dropped frompending and served
  10. 10. The waiting queue is the way to simulate the worst case scenario as explained before; thanks to it, every flownotification 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 ownedby it (for a number of slots equal to the server computation time, constant during each simulation). Thisprocess 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 movedfrom the waiting queue to the pending queue, according to Deadline Monotonic algorithm, it will be the first tobe served, deferring other notifications to be managed during the following microcycles. This might cause thesystem 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 flowgenerators in the network.Centralized control by NodesTo simplify the network, the creation of new flow generators is fully managed by Nodes. During the beginningof each microcycle, Nodes reads the beacon file and builds its timeline so that it knows where unassignedslots are located. Thus, during each empty slot, Nodes creates a new flow generator with a probabilitythreshold set in the SPAWN_FG_THR simulation variable. If a new generator is instantiated, Nodes sends toAdmission Control a registration message through the getReg() Flow class’ member function. Mind that, if noempty slot is found, no new nodes are created.Response time analysis: When the registration message arrives (Flow typed message), its data is storedby Admission Control in order to execute the response time analysis (RTA). RTA for a specific flow generatorensures that a feasible schedulation for that node is possible, considering all other already scheduledgenerators having a lower relative deadline.This implies the possibility to retrieve data from the already admitted nodes; for this reason, Admission Controlkeeps a list (class member called __flows) of the accepted flow generators to be queried everytime that RTAhas 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 isattached 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 notifiedabout the expelled node (still stored in the __gens list variable); so, every microcycle, Nodes’ internal list ofgenerators is cleared from those ones who are not scheduled in the beacon file (if a node is not admitted, itwill not appear in the file).Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 10
  11. 11. Understanding the Queue Overload phenomenonWe are now going to simulate various scenarios; before doing that it is important to point out a singularphenomenon that occurs during simulations of those scenarios aiming to test the system with a high stressfactor, acting, in particular, on the traffic intensity and uniformity (aperiodic flow generation probabilities). Morespecifically 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 aperiodicnotifications in the waiting and in the pending queue. The pending queue sorts its flows using DeadlineMonotonic algorithm which puts those flows having a higher relative deadline in the bottom of the datastructure. When we handle a large amount of traffic, the pending queue easily increases its size without aproper 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 allother flows will be served before them; meanwhile other aperiodic flows having a lower relative deadline willalways be inserted in the pending queue (as slots pass by), causing the same long deadline flows mentionedbefore stay in the bottom of the pending queue. This situation, when aperiodic flow generation probabilitiesreach a high level (about 0.45), tends to unchange, generating an incrementing residue of flows that will neverbe served.This anomaly is an intrinsic characteristic of the simulated network; it is an anomaly, not an error noran architecture imperfection. It is possible to recognize a reasonable explaination of what happensconsidering that Deadline Monotonic (used as the primary schedulation algorithm) is designed foraperiodic messages; the Queue Overload phenomenon occurs when we lead our aperiodic handlingsystem to behave like a sporadic or even periodic one, without changing the algorithm (which remainsaperiodic). This mismatching causes the Queue Overload to occur.No growth management policy is implemented for both waiting and pending queue, because it is not apurpose in aur simulations; moreover, this allows us to monitor system performance lowering in order toidentify the exact aperiodic generation probability level that leads to this problem.Real Time Systems 2010 - Final ReportDavide Giuseppe Monaco, Andrea TinoPag. 11
  12. 12. Simulation S-298993Simulation main goal: Deadline Monotonic stressing attempt evaluating QueueOverload phenomenonSimulation duration: 15.000 simulation time unitsMachine type: Pentium M 1.4 GHz, one core one CPU, Debian Linux 2.6.26Simulation 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 generationthreshold (T1)0.8 0.9Server capacity 5 slotsAperiodic deadlinedefinition threshold (T2)40 slots 60 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected62 15 47Each 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.47Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 120,20,40,60,81,0T3 T1maxT1min
  13. 13. 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.5The table shows, for those generators having a high relative deadline, very high negative delay values (andconsequently high standard deviations). Such a situation occurs because many flows are never checked bythe Polling Server when popping the pending queue, given the presence of other flows having a lower relativedeadline. Please note that data starting from FG57359’s row might be inconsistent because of the QueueOverload 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.61As it is possible to see, there is a residual number of flows that are not present in data shown in the previoustable: 4841 - 2947 - 611 is not zero! This happens because, consulting queue log files, a large amount ofunserved 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 relativedeadline greater than 45, because they have never been checked by Polling Server when popping thepending queue. Taking a look at queue log file, it is possible to notice that, during the last microcycle, thepending 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 servercapacity and trasmission behavior, leading the system to manage quasi-periodic traffic without aproper off-line schedulation.Final considerationsAs said before, this scenario shows that aperiodic real time traffic turns into quasi-periodic traffic and thathandling it with an unproper algorithm like Deadline Monotonic (not designed for such situations) does not leadto a suitable result. The same simulation has been run setting lower transmission probabilties (ranging from0.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 becauseit allows us to set up an upper bound in our simulation space. In the next scenarios we will act on aperiodicthresholds in order to make the system get near to this case, and monitor how the network behaves in verybad conditions.Given the importance of this scenario, that we will use to make several comparisons from now on, we aregoing to use refer to it as Worst case scenario.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 13
  14. 14. Simulation S-179462Simulation main goal: Low variation of relative deadlineSimulation duration: 15.000 simulation time unitsMachine type: Pentium M 1.4 GHz, one core one CPU, Debian Linux 2.6.26Simulation information and resultsIn this simulation, our aim is monitoring our network and see how efficently Polling Server can scheduleaperiodi flows having similar deadlines (low variation factor).Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 20 slotsAperiodic generationthreshold (T1)0.1 0.3Server capacity 5 slotsAperiodic deadlinedefinition threshold (T2)40 slots 50 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected745 14 731As it is possible to notice, there is an empty slot at the end of the simulation; this happens because of thescenario 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.99Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 140,20,40,60,81,0T3 T1maxT1min
  15. 15. 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.32The table shows, for each generator, a general condition that we could assume to be normal and generallyideal: mean delays are all positive and mean response times do not cross the floor of 39 slots; in thisconditions the system probably experiences a low number of deadline misses.Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio1343 1334 8 0.99As 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 fewdeadline misses (after simulation time reaches value 9.000) due to those generators having higher probabilityto transmit.Final considerationsThis is the opposite scenario to the one proposed in the first simulation: we can see the results of a normaland 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, thisscenario, 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 toset up the network in three different conditions:1. Small microcycle: There are few slots reserved for the entire microcycle, the number of flow generators issmall 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 realcase); the number of flow generators is contained and the number of flows managed by Polling Server issignificant 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 ispossible 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 networkconditions moving from the best to the worst case.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 15
  16. 16. Simulation S-297555Simulation main goal: Low number of slots, same probability of aperiodicnotification transmissionSimulation duration: 15.000 simulation time unitsMachine type: Pentium M 1.4 GHz, one core one CPU, Debian Linux 2.6.26Simulating scenario S-297555:s01Simulation information and resultsIn this simulation, our aim is monitoring our network and see how efficently Polling Server can scheduleaperiodic flows having a low capacity.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 10 slotsAperiodic generationthreshold (T1)0.19 0.21Server capacity 2 slotsAperiodic deadlinedefinition threshold (T2)20 slots 40 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected18 8 10Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio1701 1610 90 0.95As it is possible to see, having a high ratio is due to deadline generation policy: deadlines range from 20 to 40slots, a high interval.Considerations about scenarioThe first attempt of simulating this scenario was conducted using a lower deadline interval between 20 and 30slots; results reported a lower served ratio (0.88) and an empty slot could not be filled by Admission Controlat the end of the simulation. Setting a deadline upper bound generation to 40 let us reach a better admissionpolicy other than a better schedulation behavior as said before.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 160,20,40,60,81,0T3 T1maxT1min
  17. 17. Simulating scenario S-297555:s02Simulation information and resultsIn this simulation we increment deadline thresholds in order to intensify traffic in the network.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 10 slotsAperiodic generationthreshold (T1)0.34 0.36Server capacity 2 slotsAperiodic deadlinedefinition threshold (T2)20 slots 40 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected25 8 17Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio2610 1998 607 0.76Missing 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 flowgeneration probability. A general system degradation is experienced (and so it will be for the followingsimulations) 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.Scenario parametersSimulation has been configured using the following values:Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 170,20,40,60,81,0T3 T1maxT1min
  18. 18. Min (nominal) value Max valueSlot number 10 slotsAperiodic generationthreshold (T1)0.44 0.46Server capacity 2 slotsAperiodic deadlinedefinition threshold (T2)20 slots 40 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected22 8 14Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio3080 1932 788 0.63System starts experiencing the phenomenon evaluated in the S-298993 simulation (worst case); PollingServer 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 manageflows efficently until Admission Control let the last node join the network; this node has the shortest relativedeadline (20), causing Deadline Monotonic to schedule its flows before every other. From this time on, systemstarts 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.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 10 slotsAperiodic generationthreshold (T1)0.64 0.66Server capacity 2 slotsAperiodic deadlinedefinition threshold (T2)20 slots 40 slotsReal Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 180,20,40,60,81,0T3 T1maxT1min0,20,40,60,81,0T3 T1maxT1min
  19. 19. Min (nominal) value Max valueFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected34 8 26Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio3804 1914 808 0.50Polling Server schedulation performance lowers further regarding the previous scenario; in fact it is possibleto experience an incrementing flow residue inside the pending queue (for those generators having the highestdeadline) 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.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 10 slotsAperiodic generationthreshold (T1)0.79 0.81Server capacity 2 slotsAperiodic deadlinedefinition threshold (T2)20 slots 40 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected23 8 15Results about aperiodic flowsReal Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 190,20,40,60,81,0T3 T1maxT1min
  20. 20. Polling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio4257 2019 703 0.47We have 1535 never served aperiodic flow notifications in the pending queue concordently with the QueueOverload phenomenon.Considerations about scenarioComparing the worst case scenario’s served ratio, our one is even worse; this happens because S-298993scenario works using less restrictive settings.Final considerations about overall simulationThe chart shows how fastly the system performance lowers down dramatically as aperiodic flow generationthreshold increases (mind that all flow generators have almost the same probability to send an aperiodicnotification, 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, experiencesthe Queue Overload phenomenon, so that, at a certain point, it is also useless to report its mean responsetime (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 PollingServer.This chart shows the mean response time for some flow generators characterized by different relative deadlines and arrival times. Thex-axis shows the increasing level of the aperiodic flow generation threshold.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 201020304050t=0.8t=0.65t=0,45t=0.35t=0,2D = 22, r = 9D = 22, r = 21D = 23, r = 4D = 24, r = 3D = 30, r = 8D = 33, r = 5D = 36, r = 6
  21. 21. Simulation S-446696Simulation main goal: Medium number of slots, same probability of aperiodicnotification transmissionSimulation duration: 30.000 simulation time unitsMachine type: Pentium M 1.4 GHz, one core one CPU, Debian Linux 2.6.26Simulating scenario S-446696:s01Simulation information and resultsIn this simulation, our aim is monitoring our network and see how efficently Polling Server can scheduleaperiodic flows having a low capacity. In this scenario, we consider a wider microcycle.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 20 slotsAperiodic generationthreshold (T1)0.19 0.21Server capacity 5 slotsAperiodic deadlinedefinition threshold (T2)40 slots 80 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected15 15 0Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio3385 3383 0 1As it is possible to notice, this scenario represents an ideal condition; no deadline misses are experienced andall flows are managed by Polling Server. Nothing relevant to report. Served ratio is one because there are twoelements 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 specialevents to report.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 210,20,40,60,81,0T3 T1maxT1min
  22. 22. 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 networkresponse and performance.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 20 slotsAperiodic generationthreshold (T1)0.34 0.36Server capacity 5 slotsAperiodic deadlinedefinition threshold (T2)40 slots 80 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected15 15 0Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio5164 5153 4 0.99Compared to the previous scenario, the network starts experiencing a little number of dealine misses, nonsignificant as served ratio reports; furthermore, we can notice an increment less than 50% in the total numberof 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.Scenario parametersSimulation has been configured using the following values:Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 220,20,40,60,81,0T3 T1maxT1min
  23. 23. Min (nominal) value Max valueSlot number 20 slotsAperiodic generationthreshold (T1)0.44 0.46Server capacity 5 slotsAperiodic deadlinedefinition threshold (T2)40 slots 80 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected15 15 0Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio6208 6139 63 0.98Even in this conditions, the pending queue is consistent and its growth behaves normally; Deadline Monotonicresponds well.Considerations about scenarioCompared to the previous class of scenarios (S-297555), we experience a better simulation trend. In fact, itis possible to notice that, at the third scenario, the Queue Overload phenomenon doesn’t occur at all. Thismeans that a 20 slots large microcycle with deadlines set proportionally (maintaining deadline limit to 4 timesthe 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 thenetwork and the scheduling algorithm.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 20 slotsAperiodic generationthreshold (T1)0.64 0.66Server capacity 5 slotsAperiodic deadlinedefinition threshold (T2)40 slots 80 slotsReal Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 230,20,40,60,81,0T3 T1maxT1min0,20,40,60,81,0T3 T1maxT1min
  24. 24. Min (nominal) value Max valueFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected15 15 0Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio7799 6599 531 0.85A 25% increment of the total received flows is experienced by the system; furthermore, the schedulationanomaly we identified as Queue Overload occurs. More specifically, the pending queue reports a flow residueof 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 witha 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.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 20 slotsAperiodic generationthreshold (T1)0.79 0.81Server capacity 5 slotsAperiodic deadlinedefinition threshold (T2)40 slots 80 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected15 15 0Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 240,20,40,60,81,0T3 T1maxT1min
  25. 25. Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio8753 6601 529 0.75As predicted, an total managed flow increase is experienced and a lesser ratio can be noticed; however itis remarkable that the number of deadline misses has grown by 2 elements only. This situation is due to theoccuring of the Queue Overload phenomenon which causes amost 6000 flows to stagnate inside the pendingqueue.Considerations about scenarioSystem performance lowers dramatically compared to the previous scenario, but we must always considerthat 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 tobetter tolerate a major amount of aperiodic traffic. A less number of deadline misses is experienced as well forthe served flow ratio. More specifically, it is remarkable how the schedulation algorithm is able to maintain agood trend in performance and flow management.Looking at the chart showing the mean response time reported by the most significant generators, it ispossible to notice that these scenarios define a better condition for the overall system. In fact, all flowgenerators, experience a response time generally positioned at the same level. Of course, the QueueOverload 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 schedulationThis chart shows the mean response time for some flow generators characterized by different relative deadlines and arrival times. Thex-axis shows the increasing level of the aperiodic flow generation threshold. Among all flow generators, the most significant has beenselected for plotting simulation data.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 2520304050t=0.8t=0.65t=0,45t=0.35t=0,2D = 40, r = 19D = 48, r = 20D = 50, r = 14D = 80, r = 13D = 45, r = 10D = 58, r = 12D = 48, r = 7D = 64, r = 9D = 64, r = 11D = 76, r = 16
  26. 26. anomaly. This is sure a better result if compared to the general trend experienced in the previos simulationeven because the system does not differ in other parameters given that the microcycle has been enlargedproportionally, so that the server capacity and the simulation overall time have been consequently incrementedtoo.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 26
  27. 27. Simulation S-896332Simulation main goal: High number of slots, same probability of aperiodicnotification transmissionSimulation duration: 75.000 simulation time unitsMachine type: Pentium M 1.4 GHz, one core one CPU, Debian Linux 2.6.26Simulating scenario S-896322:s01Simulation information and resultsIn this simulation, our aim is monitoring our network and see how efficently Polling Server can scheduleaperiodic flows having a low capacity but a higher number of flow generators.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 50 slotsAperiodic generationthreshold (T1)0.19 0.21Server capacity 12 slotsAperiodic deadlinedefinition threshold (T2)100 slots 200 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected51 38 13Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio8936 8925 0 1No 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 generaltraffic intensification.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 270,20,40,60,81,0T3 T1maxT1min
  28. 28. Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 50 slotsAperiodic generationthreshold (T1)0.34 0.36Server capacity 12 slotsAperiodic deadlinedefinition threshold (T2)100 slots 200 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected52 38 14Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio13597 13584 4 0.99It 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 whenthe aperiodic generation threshold is lead to a medium level.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 50 slotsAperiodic generationthreshold (T1)0.44 0.46Server capacity 12 slotsAperiodic deadlinedefinition threshold (T2)100 slots 200 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 280,20,40,60,81,0T3 T1maxT1min0,20,40,60,81,0T3 T1maxT1min
  29. 29. Total requests Admitted Rejected56 38 18Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio16086 15921 150 0.98As we can see, performance lowering is represented by a significant increment of the number of deadlinemisses. 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 numberof 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 whenconditions get worse.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 50 slotsAperiodic generationthreshold (T1)0.64 0.66Server capacity 12 slotsAperiodic deadlinedefinition threshold (T2)100 slots 200 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected51 38 13Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio19797 16560 1056 0.84As aperiodic flow generation threshold increases, the number of processed flows grows significantly. In thisReal Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 290,20,40,60,81,0T3 T1maxT1min
  30. 30. case, we experience also a remarkable higher value of deadline misses. Furthermore the Queue Overloadphenomenon 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 experiencedduring the other simulations; although this might be considered a good factor, we must consider the presenceof the Queue Overload which pollutes our statistical data.Simulating scenario S-896322:s05Simulation information and resultsIn this simulation we reach the worst case scenario.Scenario parametersSimulation has been configured using the following values:Min (nominal) value Max valueSlot number 50 slotsAperiodic generationthreshold (T1)0.79 0.81Server capacity 12 slotsAperiodic deadlinedefinition threshold (T2)100 slots 200 slotsFlow generatorspawning threshold (T3)1.0Results about flow generatorsDuring simulation, Admission Control’s activity about registration request management is summarized below:Total requests Admitted Rejected64 38 26In this case, differently from the other scenarios, we experience a significant increment of the total number ofrequests send to Admission Control.Results about aperiodic flowsPolling Server statistics regarding aperiodic flows management are shown below:Total received flows Served Deadline Misses Served ratio22237 16839 777 0.75As shown in the table, we experience a significant lowering of performance. Although the number of deadlinemisses is lower regarding the previous scenario, this information, unfortunately, is highly corrupted by theQueue Overload phenomenon. In fact, opening the log file showing the queue content, we find that flowresidue in the pending queue is about 4600.Considerations about scenarioReal Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 300,20,40,60,81,0T3 T1maxT1min
  31. 31. 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, thereare little variations showing that this simulation provides a better configuration from the point of view of theresponse 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. Thex-axis shows the increasing level of the aperiodic flow generation threshold. Among all flow generators, the most significant has beenselected for plotting simulation data.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 31406080100120t=0.8t=0.65t=0.45t=0.35t=0.2D = 114, r = 99D = 129, r = 39D = 107, r = 32D = 147, r = 15D = 147, r = 23D = 111, r = 14D = 116, r = 17D = 106, r = 29D = 129, r = 26D = 195, r = 35
  32. 32. Summarizing simulationsSimulations: S-297555, S-446696, S-896322Summarizing served ratioConsidering the three simulations it is possible to notice how the last two are equivalent from the point of viewof 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 otherThis 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.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 32S-2975550,40,60,81,0t = 0.8t = 0.65t = 0.45t = 0.35t = 0.2S-446696S-896332S-297555020040060080010001200t = 0.8t = 0.65t = 0.45t = 0.35t = 0.2S-446696S-896332
  33. 33. simulations experience considerable variations. Please note that the values reported for the last scenario (foreach simulation) are strongly polluted by the Queue Overload phenomenon that makes impossible to correctlycollect statistical data. Note also that the final variations in the curves can measure the pollutioning levelexperienced by every simulation.Real Time Systems 2010 - SimulationsDavide Giuseppe Monaco, Andrea TinoPag. 33
  34. 34. 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>.logwhere:• 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 containinformation 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 everysimulated 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 asignificant event occurs and at the end of the simulation. At runtime, the file is filled with lines reportingthe most important events during the simulation (like a deadline miss or a flow to be moved in the pendingqueue). The file is finally closed when the simulation finishes; in this case Polling Server appends severalinformation regarding overall simulated scenario (like the total number of deadline misses) and statisticsabout every single flow generator, providing useful information about produced traffic and its maincharacterization.2. Admission Control log file (example: log_ac_001.log): Admission Control writes this file at runtimeeverytime that a new flow generator attempts to join the network; in this case the file reports the hesit ofthe admission test and the joining generator information. Admission Control finally closes the file when thesimulation 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 filestores the most important information about flow generators settings (like the total number of generatedflows). 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 TinoAppendix
  35. 35. 4. Queues log file (example: qlog_001.log): This file is written by Polling Server and provides a way forlooking inside the waiting and the pending queue during every beacon slot. This file can be used forchecking ther queues’ state after the simulation.Logging functionsTo implement logging functionality, the source files in the project are filled with special private memberfunctions and variables recognizable by the “log“ prefix. It is highly recommended not to modify these functionsin order not to loose the logging system (tested at development time).Real Time Systems 2010 - AppendixesDavide Giuseppe Monaco, Andrea TinoAppendix
  36. 36. Simulation reports’ glossaryThe simulations section of this document shows several data structures, tables and charts in order to presentsimulation results in the most affordable and easy to understand way. Some acronyms and abbreviations arepresent though.Abbreviations and symbolsAbbreviations and special character symbols used in simulation reports are the following (attention, allabbreviations are case sensitive):Abbreviation Places to find it DescriptionTot Table headers Indicates the total number of flows generated by a particularflow 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 timeof a flow generator (attempting to join the network) registrationmessage.WCRT Table headers Indicates the Worst Case Response Time evaluated byAdmission Control when admitting a new flow generator.Pr{Tx} Table headers Indicates the probability to transimt an aperiodic flow for a flowgenerator.R.T. Table headers Indicates the Response Time of a flow (scheduled and servedby Polling Server).σ Table headers Indicates the standard deviation.delay Table headers Indicates the range of time starting from when an aperiodic flowis created to the time when it is served.Min Table headers Indicates the minimum numeric value inside a series ofnumbers.Max Table headers Indicates the maximum numeric value inside a series ofnumbers.FG Table headers, tables sidecellsIndicates a flow generator (usually followed by its numericidentifier).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 muchbefore the flow has been managed (defore its deadline). If the value is negative, we have a deadline missreported after delay time units.Real Time Systems 2010 - AppendixesDavide Giuseppe Monaco, Andrea TinoAppendix

×