Difference between revisions of "Ruby Network Test"
(Started networktest documentation) |
(Documentation for networktest) |
||
Line 1: | Line 1: | ||
==Ruby Network Tester== | ==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 | + | 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 [[Ruby#Network_test|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 === | === How to run === | ||
− | + | First build GEM5 with the [[Ruby#Network_test|Network_test]] coherence protocol: | |
+ | |||
+ | '''scons build/ALPHA_SE_Network_test/m5.debug''' | ||
+ | |||
+ | |||
+ | Sample command to run: | ||
+ | |||
+ | '''./build/ALPHA_SE_Network_test/m5.debug configs/example/ruby_network_test.py --num-cpus=16 --num-dirs=16 --topology=Mesh --mesh-rows=4 --maxtick=1000 --injectionrate=0.01 --synthetic=0 --fixed-pkts --maxpackets=1 --garnet-network=fixed''' | ||
+ | |||
+ | {| border="1" cellpadding="10" class="wikitable" | ||
+ | ! 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 [[Ruby#Topology|here]]. | ||
+ | |- | ||
+ | | '''--mesh-rows''' || The number of rows in the mesh. Only valid when ''--topology'' is ''Mesh'' or ''MeshDirCorners''. | ||
+ | |- | ||
+ | | '''--maxticks''' || 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 ''-p'') from each cpu. This is useful for network debugging. If this parameter is not declared, cpus will keep injecting at the specified rate till ''-m'' 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 [[Ruby#garnet|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. | ||
+ | * 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 [[Ruby#Network_test|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. |
Revision as of 05:05, 29 March 2011
Contents
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.
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_SE_Network_test/m5.debug
Sample command to run:
./build/ALPHA_SE_Network_test/m5.debug configs/example/ruby_network_test.py --num-cpus=16 --num-dirs=16 --topology=Mesh --mesh-rows=4 --maxtick=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. |
--maxticks | 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 -p) from each cpu. This is useful for network debugging. If this parameter is not declared, cpus will keep injecting at the specified rate till -m 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.
- 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.