Hi ZiFeng, The latencies you are reporting are in simulation ticks. The simulation clock is usually set at 1,000 GHz by default, making a 6,250 latency (the first value you are reporting) correspond to a 6.25 ns latency, which is in the right ballpark, I guess. Considering the Ruby system runs at 2 GHz by default, it makes for a 12.5 cycles latency. You will have to do that conversion yourself. Also be careful with *Unspecified unit* stats. They might not always be in ticks. If you have a doubt, check the source to confirm how is a given stat computed.
Regarding the number of packets injected, you are asking for the simulation to run for 10,000 simulation cycles, a.k.a., 10,000 ticks (1THz). The 0.02 injection rate, however, is per CPU cycles (! GHz). The same as above applies : you are effectively asking for each CPU to send a packet every 50 cycles, that is every 50,000 simulation ticks. The simulation running for 10,000 ticks, only 1 in 5 CPU gets to send a packet, which should yield 12.8 accesses in total. Given the law of large numbers does not apply very well in your scenario, getting 10 accesses is, again, in the right ballpark. I suggest that you crank up dramatically sim-cycles. Pro tip: if a 64 cpus / 64 dirs Garnet simulation runs fast, then something went wrong ;) Best, Gabriel
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
