IV) Implementation of Simulator

An overview of the class structure used to implement this simulator is shown in appendix III. Specific topologies in this simulator are implemented as classes derived from the topology base class. A specific topology constructor is used create all of the nodes as elements of the nodes[] array and set all the links of each node to point to the nodes which are connected to that node. Specific topologies also provide a router(...) function which is called by the traffic generator functions provided by the parent topology class.
In all I had planned to construct three traffic generators: a random traffic generator, a hot spot traffic generator, and a data mover (page migration) traffic generator. While implementing the simulator, I determined that using a stilted packet length array in either the hotspot or random traffic generators would suffice for a data mover traffic generator. The random traffic generator is fed with an packet lengths array as defined in config.h which specifies the equally weighted possibilities of the length of a new packet to be injected per node per simulation cycle. The packet lengths array is an offset exponential length of len = 2^(n-1) words with 0 meaning that no output packet is produced. As an example, a length input array of {3,3,1,1,1,0,0,0} would produce a 25% chance of a packet of length four words, 37.5% chance of a packet of length one word, and 37.5% chance of no packet being injected from this node. For standard hotspot traffic and random traffic simulation results I used the preceding packet length array for lack of any justified values, and for data moving traffic simulations I used the the packet length array of {8,8,8,1,1,0,0,0,0}. The simulator does not actually produce packets of this length but rather only packet headers which specify the packet length. To facillitate for transmitting a packet of length exceeding a per-cycle link bandwidth, I took the simple approach that once a link begins routing a packet it must continue to route only that packet until all the data words are sent. As soon as a packet is able to route along a link its position is updated so that next cycle it can be advanced, but the link is prevented from routing any additional packets until the cycles required to send a packet of that length have elapsed. This is complies with packet forwarding routing, and could also be used to simulate wormhole routing by using large packet lengths.
The random traffic generator operates by traversing each node in the node[] array of a topology instance and generating a packet of length randomly chosen from the packet length array (specified as input for the simulation run). This packet (if not of zero length) is assigned a random destination and injected into the pkts[] heap with its location (= source) as the currently chosen node in the node[] array.
The hotspot traffic generator is used to illustrate bottleneck links within a topology. For this traffic generator a single node (the hotpsot) is chosen as either the source or destination of every simulation packet. Whether the packets are injected from the hotspot (i) or routed to the hotspot (r), is determined by a simulation parameter representing the ratio i/(i+r). This way a simulation run of all injects from the hotspot may be specified with the forementioned ratio set to 1 (since x/(x+0) = 1), and a run of all routes to the hotspot can be specified by a ratio of 0 (since 0/(0+x) = 0). The hotspot traffic generator uses an algorithm to randomly approach this ration, so that regular traffic patterns of i and r will not occur. The unspecified partner of the (source, destination) pair in the hotspot traffic generator is randomly, and the packet length is chosen in the same manner as in the random traffic generator.
Traffic generators in this simulator route in a first queued, first routed fashion which should be fairly consistent in giving the oldest packet preference since the new packets injected into the IN each simulation cycle are placed at the end of the pkts[] heap. For the simulations I have performed livelock is not an issue since all simulation routers are minimal routers.
When I began coding the project I had written individual classes for the de Bruijn and hypercube topologies, but after writing and optimizing the router for the mdsxn topology, I realized that it was able to route in a hypercube and de Bruijn topology just as well as the original routers, and therefore I changed the de Bruijn and hypercube implementations to functions which instantiate an equivalent mdsxn network.
All the coding for this project was done in C++ and compiled and tested using Gnu g++ egcs-2.90.27 and Linux 2.1.121 for i586. Most of the time used on this project was spent developing and debugging the simulator, and not researching or documenting. In addition I wrote a stand alone program to read the raw data file output of the simulator results and plot it using a freeware X11 3d plotting library, plplotlib. Further details of the simulator implementation can be extracted from the well commented simulator source code.