Tests with a simple topology

After the tests with a super-simple model we created a small 6-node topology to focus on the definition of the base elements of a Network.

Network Elements

We created atomic models and c++ clases to represent the fundamental elements in a network:

  • Server: it generates new packets based on the flows assigned to it
  • Link: it is a coupled model (maybe in the future would be good to make it a single atomic model to improve performance).
    It applies a delay to the packets based on their size. While a packet is being transmited, other arriving packets are queued. This queue represents the NIC buffer where the link is connected to. It might be strage to think that the queue is inside the Link model...
  • Router: it receives packets from an inPort and forwards them to an outPort base on the packet's route
  • Sink: receives packets and logs some measurements (ej: residenceTime, received_bits, etc).
With this models simple topologies can be defined using the GUI. For model complex topologies, the first step is to be able easily instanciate these models in c++ code (some ideas here). In a later future a high-level language to define a topology can generate that c++ code.


  • Route: represents a path that packets take in order to go from a source node (eJ: a Server) to a destination node (ej: aPacketSink), traversing other network nodes (Ej: Routers).
  • Flow: Flows (or classes in the the MVA parlance) define the communication between different nodes. Flows define the rate at which packets are generated, the size of the packets, and the route these packets will take.
  • FlowDefinitions: a static class where all the flows of the system are defined.
The Twiki here explains these classes, how to create instances and use them.

Now flows can be defined in c++ code. Easily if there are not too many flows. In a later future a high-level language to define a topology can generate that c++ code.

Simple Topology

For this topology we defined 2 flows as follows:

void FlowDefinitions::defineFlows(){
FlowDefinitions::addFlow(0, std::make_shared<ExponentialDistributionParameter>((double)1/15),
std::make_shared<ExponentialDistributionParameter>(1000*8), {
{0, "FelixServer1"},
{0, "Router1"},
{0, "Router2"},

std::shared_ptr<Flow> flow (new Flow(0, std::make_shared<ExponentialDistributionParameter>((double)1/35),
{0, "FelixServer2"},
{0, "Router1"},
{1, "Router2"},

Performance improvement

Performance was improved compared to the measurements performed in Comparison of PowerDEVS, JMT and JMT-MVA (with a super simple model) as follows:

  1. The QueueSamplers were removed and now using the SamplerLogger. This improves performances, as each link was one less atomic model.
    Farther improvement can be achieved by changing the NetworkQueue as not to produce "notification" events, as they are not needed anymore
  2. The C++ optimization flag was set to -O3 (before we were using -O1 frown ).
Results: a model that before was taking ~180s to execute, now takes ~110s. More tests should be performed to compare against JMT


  • Perform some test to verify the model, and compare with JMT.
  • Evaluate to make the link (queue+server+sampler) a single atomic model to improve performance.
  • Add a delay to the routers.
  • It might be strage to think that the queue is inside the Link model...
  • Add queueing policies to routers. This will require thinking the best way for the Router model to get the information of all queues (now inside the Link model) connected to it.
    This might be a problem because of putting the queue inside the link... maybe rethink..
  • Think of a mechanism to read flow parameters from the configuration.
-- MatiasAlejandroBonaventura - 2016-06-15
Edit | Attach | Watch | Print version | History: r9 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2016-06-22 - MatiasAlejandroBonaventura
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback