1 |
54 |
alirezamon |
= SynFull Traffic Generator 1.0
|
2 |
|
|
|
3 |
|
|
Included is the source code for generating traffic based on models created for a full-system simulation as configured in the paper.
|
4 |
|
|
The models generate traffic according to 32 nodes, 16 of which are private L2 caches and the other 16 are directories.
|
5 |
|
|
You can map these nodes to your network simulator however you like.
|
6 |
|
|
Even numbered nodes are the caches, while odd numbered nodes are directories.
|
7 |
|
|
|
8 |
|
|
== Source Files
|
9 |
|
|
|
10 |
|
|
The src directory includes the source code for the traffic generator.
|
11 |
|
|
Most of the code is commented for your convenience.
|
12 |
|
|
It uses several global variables to keep implementation simple - that is, probability distributions and other model information are easily accessible anywhere.
|
13 |
|
|
|
14 |
|
|
The traffic generator uses a file socket to communicate as defined in the src/netstream directory.
|
15 |
|
|
In this implementation, SynFull is the client.
|
16 |
|
|
As such, you must modify your network simulator to act as the server.
|
17 |
|
|
An example of how to do this is shown in NetworkInterface.cpp.
|
18 |
|
|
The traffic generator and your network simulator will work in lock-step during the simulation, incrementing by one cycle at a time.
|
19 |
|
|
|
20 |
|
|
== Step-by-Step Guide
|
21 |
|
|
|
22 |
|
|
This section describes the steps you need to do in order to run SynFull with your desired network simulator.
|
23 |
|
|
|
24 |
|
|
=== Modifying the Network Simulator
|
25 |
|
|
|
26 |
|
|
Step 1:: Identify the portions of code in your network simulator where:
|
27 |
|
|
** The network is initialized
|
28 |
|
|
** The network progresses to the next cycle in the simulation
|
29 |
|
|
** packets are injected (e.g. into routers).
|
30 |
|
|
** packets have reached their destination
|
31 |
|
|
|
32 |
|
|
Step 2:: Based on the portions of code identified in Step 1, you'll want to extract packets from NetworkInterface.cpp to inject and notify NetworkInterface.cpp of packets that have arrived.
|
33 |
|
|
One possible implementation is to use two queues - NetworkInterface will populate one queue with packets to be injected, and remove packets from another queue for packets to be "ejected" (i.e. they have reached their destination).
|
34 |
|
|
|
35 |
|
|
Step 3:: When the network is initialized, NetworkInterface::Init should be called in order to set up the network simulator as a server.
|
36 |
|
|
NetworkInterface will then "listen" on a file socket for a connection.
|
37 |
|
|
Once a connection has been established with the TrafficGenerator, your network simulator will proceed to initialize everything else.
|
38 |
|
|
|
39 |
|
|
Step 4:: For the portion of code where the network simulator progresses to the next cycle, call the NetworkInterface::Step function to receive packets from the TrafficGenerator and notify it of packets that have arrived.
|
40 |
|
|
Continueing from the previous example, this can be done by populating and depopulating queues with packets.
|
41 |
|
|
|
42 |
|
|
=== Running the Modified Network Simulator
|
43 |
|
|
|
44 |
|
|
Step 1:: Run your network simulator, it should stop during initialization and wait for a connection before proceeding.
|
45 |
|
|
|
46 |
|
|
Step 2:: Run the TrafficGenerator, indicating the model file, the desired number of cycles to simulate, and whether or not the simulation should end prematurely due to steady state (use 1 as the argument to end prematurely, 0 otherwise).
|
47 |
|
|
A connection should be established and packets will be injected and ejected from the network simulator on a cycle by cycle basis.
|
48 |
|
|
|
49 |
|
|
Example 1:: Run barnes for 10 million cycles and exit on steady state
|
50 |
|
|
|
51 |
|
|
./tgen ../models/barnes.model 10000000 1
|
52 |
|
|
|
53 |
|
|
Example 2:: Run bodytrack for 50 million cycles
|
54 |
|
|
|
55 |
|
|
./tgen ../models/bodytrack.model 50000000 0
|
56 |
|
|
|
57 |
|
|
[WARNING]
|
58 |
|
|
====
|
59 |
|
|
You must run the traffic generator and your network simulator server from the same directory.
|
60 |
|
|
This is because the file socket is created in this directory.
|
61 |
|
|
You can modify this if you wish.
|
62 |
|
|
Also, you must not run more than one server in the same directory at a time.
|
63 |
|
|
You can also modify this if you want by using different file descriptors for different socket connections, but the current code does not support this.
|
64 |
|
|
====
|
65 |
|
|
|
66 |
|
|
== Conclusion
|
67 |
|
|
|
68 |
|
|
This is only one application of our methodology.
|
69 |
|
|
You can adapt the methodology to a number of different configurations and coherence protocols by using the same tools: volume distributions, spatial distributions and flows, and sharing patterns (e.g. modelling invalidates/forwarded requests at different directories).
|