Difference between revisions of "Ruby Network Test"

From gem5
Jump to: navigation, search
(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 using the garnet network.
+
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'''
  
:: '''Related Files''':
 
::::  src/cpu/testers/networktest/networktest.hh
 
::::  src/cpu/testers/networktest/networktest.cc
 
  
 
=== How to run ===
 
=== How to run ===
  
TODO
+
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]].
 +
|}
 +
 
 +
 
  
=== networktest.cc ===
+
=== Implementation of network tester ===
  
TODO
+
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 10:05, 29 March 2011

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.