Difference between revisions of "Ruby Network Test"
From gem5
m (→How to run) |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | 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. | |
| − | |||
| − | 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 [[ | ||
=== Related Files === | === Related Files === | ||
| Line 13: | Line 11: | ||
=== How to run === | === How to run === | ||
| − | First build gem5 with the [[ | + | First build gem5 with the [[Network_test]] coherence protocol: |
<pre>scons build/ALPHA_Network_test/gem5.debug</pre> | <pre>scons build/ALPHA_Network_test/gem5.debug</pre> | ||
| Line 20: | Line 18: | ||
Sample command to run: | Sample command to run: | ||
| − | <pre>./build/ALPHA_Network_test/gem5.debug configs/example/ruby_network_test.py --num-cpus=16 --num-dirs=16 --topology=Mesh --mesh-rows=4 | + | <pre>./build/ALPHA_Network_test/gem5.debug configs/example/ruby_network_test.py \ |
| − | --sim-cycles=1000 --injectionrate=0.01 --synthetic=0 --fixed-pkts --maxpackets=1 --garnet-network=fixed</pre> | + | --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</pre> | ||
{| border="1" cellpadding="10" class="wikitable" | {| border="1" cellpadding="10" class="wikitable" | ||
| Line 46: | Line 50: | ||
| '''--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 [[Interconnection_Network#Garnet_Networks|here]]. | | '''--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 [[Interconnection_Network#Garnet_Networks|here]]. | ||
|} | |} | ||
| − | |||
| − | |||
=== Implementation of network tester === | === Implementation of network tester === | ||
| Line 59: | Line 61: | ||
* This destination is embedded into the bits after block offset in the packet address. | * 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 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 [[ | + | * 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 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. | * The cache controller injects the LD, IFETCH and ST into virtual networks 0, 1 and 2 respectively. | ||
Latest revision as of 22:56, 8 December 2013
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.
Related Files
- configs/example/ruby_network_test.py: file to invoke the network tester
- src/cpu/testers/networktest: files implementing the tester.
- NetworkTest.py
- networktest.hh
- networktest.cc
How to run
First build gem5 with the Network_test coherence protocol:
scons build/ALPHA_Network_test/gem5.debug
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
| Parameter | Description |
|---|---|
| --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.
