-
Notifications
You must be signed in to change notification settings - Fork 12
TrafficPatterns
###Synthetic Traffic Patterns### Here you can find the general shape of the tag corresponding to traffic description in simulation.sgml file.
<TrafficPattern id="MULTICAST" type=RANDOM numMessTypes=4 probMulticast=1 lengthMulticast=8>
Some values, such as id, type or numMessTypes are employed in every traffic generated, while others are specific of the traffic model selected (like probMulticast and lengthMulticast for MULTICAST model). The numMessTypes variable defines the number of different message types that are going to be generated.
###Models###
The id variable from the tag identifies a set of characteristics only available in the traffic model selected. The ones available in TOPAZ at this moment are:
MODAL: This could be considered the baseline configuration. Plain traffic generation, all the messages have the same length and a single destination. No additional variables are needed to define it.
BIMODAL: This traffic model generates packets of two different lengths. The fraction and length of the second kind of messages must be defined through two additional variables that must be included in the traffic tag. prob defined the probability of generating one message of the length defined in numMsg. It must be noticed that this mixture of message sizes is the usual shape of communication, where data requests have usually a small size while replies carrying the data require a larger number of bytes.
MULTICAST: In this model, messages with multiple destinations are mixed with messages with a single destination. Again, the fraction of multicast messages, and the number of destinations of each one is defined through two variables that must be included in the tag, probMulticast adn lengthMulticast. See the section for more details about this.
REACTIVE: In the previous models, the generation of a message is not related to any network event. This is not the common case, where some message generate as a consequence of the arrival of previous ones. To model this behavior, we propose this kind of traffic, where injectors only generate the firts messages in the dependency chain (messType=1). The rest of message types are generated as a consequence of the consumption of another message. For this new message generated, the destination is selected as the source node of the previous message.
As explained before, the distribution of sources and destinations for the messages generated corresponds to communication patterns in numerical algorithms. The id variable determines which is the pattern selected for the simulation. Any traffic model described in previous section can make use of all the traffic patterns. The only peculiarity to take into account is that in MULTICAST model, those messages with multiple destinations always correspond to uniform distributions. The patterns available in TOPAZ are:
RANDOM: (also known as uniform) In this kind of pattern, source and destination is selected randomly for each message generated.
BIT REVERSAL: Fixed source-destination pair for every message. The node with binary value an-1, an-2,..., a1, a0 communicates with the node a0, a1,..., an-2, an-1.
PERFECT SHUFFLE: Fixed source-destination pair for every message. The node with binary value an-1, an-2, ..., a1, a0 communicates with the node an-2, an-3, ..., a0, an-1 (rotate left 1 bit).
TRANSPOSE MATRIX: Fixed source-destination pair for every message. The node with binary value an-1, an-2, ..., a1, a0 communicates with the node an/2-1,..., a0, a,n-1, ..., an/2.
TORNADO: Fixed source-destination pair for every message. The node with decimal coordinates [x,y] (bi-dimensional), communicates with the node [(x+(k/2-1)) mod k, (y+(k/2-1)) mod k], where k represents the size of the network in both x and y dimensions.
LOCAL: Source node is generated randomly for every message. Destination is also generated randomly, but an additional condition must be accomplished. Destination has to be at a maximum distance of sigma from source node, being sigma a value that must be defined in the traffic tag.
HOT SPOT:
The traffic tag which should be applied either in the simulation .sgm file or in the command option is shown below:
| Traffic Pattern | Associated Tag |
|---|---|
| Random | RANDOM |
| Bit Reversal | BIT-REVERSAL |
| Perfect Shuffle | PERFECT-SUFFLE |
| Transpose Matrix | PERMUTATION |
| Tornado | TORNADO |
| Local | LOCAL |
###Trace Driven Simulations###
TOPAZ is able to run simulations where message generation is peformed according to a file that is dynamically read as simulation time advances. The traffic pattern tag employed in this case is shown below:
<TrafficPattern id="MODAL" type=TRACE traceFile="prueba.trace" numMessTypes=5>
As can be seen, type variable must be set to TRACE value, and the name of the file must be added to the tag. Trace file is expected to be found in the same directory as the TOPAZ executable. For the moment, an extremely simple format of trace file is implemented, but its modification to accept different file formats is rather easy. Inside a trace file you will find something similar to this:
10 3 3 0 0 0 0 1
20 2 2 0 1 1 0 1
30 1 1 0 2 2 0 1
40 2 1 0 1 2 0 1
The meaning of each column is the following (first line as example):
| Source | Dest | ||||||
|---|---|---|---|---|---|---|---|
| Generation Time | X coord | Y coord | Z coord | X coord | Y coord | Z coord | Size |
| 10 | 3 | 3 | 0 | 0 | 0 | 0 | 1 |
###Full System Simulation###
When network traffic is generated by a different simulation tool running in parallel with TOPAZ, we only have to make sure that no messages are generated internally by TOPAZ. To do so, we always must ensure that the type variable in traffic tag is set to EMPTY value. An example of this configuration is shown below.
<TrafficPattern id="MODAL" type=EMPTY numMessTypes=4>