Difference between revisions of "Ruby Network Test"
m (Nilayvaish moved page Networktest to Ruby Network Test without leaving a redirect: The page is being moved so as to differentiate between the coherence protocol Network test and the tester it self.)
Revision as of 23:29, 8 July 2013
Ruby Network Tester
The Ruby Network Tester provides a framework for simulating the interconnection network with controlled inputs. This is useful for network testing/debugging, or for network-only simulations with synthetic traffic (especially with the garnet network). The tester works in conjunction with the Network_test coherence protocol.
- configs/example/ruby_network_test.py: file to invoke the network tester
- src/cpu/testers/networktest: files implementing the tester.
How to run
First build gem5 with the Network_test coherence protocol:
Sample command to run:
./build/ALPHA_Network_test/gem5.debug configs/example/ruby_network_test.py --num-cpus=16 --num-dirs=16 --topology=Mesh --mesh-rows=4 --sim-cycles=1000 --injectionrate=0.01 --synthetic=0 --fixed-pkts --maxpackets=1 --garnet-network=fixed
|--num-cpus||Number of cpus. This is the number of source (injection) nodes in the network.|
|--num-dirs||Number of directories. This is the number of destination (ejection) nodes in the network.|
|--topology||Topology for connecting the cpus and dirs to the network routers/switches. The Mesh topology creates a network with --num-cpus number of routers/switches. It requires equal number of cpus and dirs, and connects one cpu, and one dir each to one network router. More detail about different topologies can be found here.|
|--mesh-rows||The number of rows in the mesh. Only valid when --topology is Mesh or MeshDirCorners.|
|--sim-cycles||Total number of cycles for which the simulation should run.|
|--injectionrate||Traffic Injection Rate in packets/node/cycle. It can take any decimal value between 0 and 1. The number of digits of precision after the decimal point can be controlled by --precision which is set to 3 as default in ruby_network_test.py.|
|--synthetic||The type of synthetic traffic to be injected. Currently, 3 types of synthetic traffic: uniform-random (--synthetic=0), tornado (--synthetic=1), and bit-complement (--synthetic=2) can be injected by the tester code in networktest.cc.|
|--maxpackets||Maximum number of packets to be injected by each cpu node. This parameter only works when --fixed-pkts is declared. This is useful for network debugging.|
|--fixed-pkts||Inject only a fixed number of packets (specified by --maxpackets) from each cpu. This is useful for network debugging. If this parameter is not declared, cpus will keep injecting at the specified rate till --sim-cycles cycles when the simulation ends.|
|--garnet-network||Enables the garnet network. This parameter can take two values: fixed and flexible. More details about these two garnet networks can be found here.|
Implementation of network tester
The network tester is implemented in networktest.cc. The sequence of steps involved in generating and sending a packet are as follows.
- Every cycle, each cpu performs a bernouli trial with probability equal to --injectionrate to determine whether to generate a packet or not. If --fixed-pkts is enabled, each cpu stops generating new packets after generating --maxpackets number of packets. The tester terminates after --sim-cycles.
- If the cpu has to generate a new packet, it computes the destination for the new packet based on the synthetic traffic type (--synthetic).
- 0 (Uniform Random): send to a destination directory chosen at random from the available directories.
- 1 (Tornado): send to the destination directory half-way across X dimension. This only makes sense for Mesh or Torus topologies.
- 2 (Bit-Complement): send to the destination directory whose location is the bit-complement of the source cpu location. This only makes sense for Mesh or Torus topologies.
- This destination is embedded into the bits after block offset in the packet address.
- The generated packet is randomly tagged as a ReadReq, or an INST_FETCH, or a WriteReq, and sent to the Ruby Port (src/mem/ruby/system/RubyPort.hh/cc).
- The Ruby Port converts the packet into a RubyRequestType:LD, RubyRequestType:IFETCH, and RubyRequestType:ST, respectively, and sends it to the Sequencer, which in turn sends it to the Network_test cache controller.
- The cache controller extracts the destination directory from the packet address.
- The cache controller injects the LD, IFETCH and ST into virtual networks 0, 1 and 2 respectively.
- LD and IFETCH are injected as control packets (8 bytes), while ST is injected as a data packet (72 bytes).
- The packet traverses the network and reaches the directory.
- The directory controller simply drops it.