Just something else I recently figured out ( from
http://www.m5sim.org/Ruby_Network_Test) is that the directory controller drops
the packet. Does that just mean that the system instantly knows the location of
the memory and its current state? It seems like the Ruby memory tester is
slowly losing its appeal for use in my project, as it is a bit confuding to
what it does compared to a regular system.
________________________________
From: Alex Tomala <[email protected]>
To: "[email protected]" <[email protected]>
Sent: Saturday, September 21, 2013 7:41:46 PM
Subject: Issues testing a memory system in Ruby
I am currently trying to figure out the best method to test two different
multi-core memory systems in Ruby. I can't use SE mode as Alpha doesn't support
PThreads for it, so I am thinking of using FS mode or ruby_network_test. I am
thinking of connecting a CommMonitor to each CPU while testing it to collect
data on latency. The main issue right now is that the latency doesn't seem to
give proper results. When I run the following command (Mesh with only one row):
./gem5/gem5-stable.build/ALPHA_Network_test/gem5.debug
gem5/gem5-stable/configs/example/ruby_network_test.py --num-cpus=64
--num-dirs=64 --topology=Mesh --sim-cycles=1000 -injectionrate=1 --mesh-rows=1
I get an average latency of approximately 4.9132. When I run the same
simulation with --mesh-rows=8 (Make the mesh a square) I get the exact same
latency. I am wondering what would cause this similarity, as I assume that
having 8 mesh rows would decrease the latency.
The latency also seems to scale up very efficiently (1 CPU = average of 4; 64
CPU = average of 4.9132), which makes no sense to me.
I would like to mention that I am using the
"system.monitors.readLatencyHist::mean" statistics (which comes from
CommMonitor) when calculating the average latency.
- Alex
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
