Thank you. I just to make sure that I understood it the right way. In the file network/Network.py, in the declaration of RubyNetwork class control message size is defined as
*control_msg_size = Param.Int(8, "");* * * So the control message size (m_control_msg_size) is 8 bytes. According to network/Network.cc, the data message size (m_data_msg_size) is *m_data_msg_size = RubySystem::getBlockSizeBytes() + m_control_msg_size* * * >From ruby/system/RubySystem.py, *block_size_bytes = Param.Int(64, "default cache block size")* * * Therefore, m_data_size = 64+8 = 72 bytes. Since the flit size is 16 bytes, an 8 byte control message takes 1 flit and 72 bytes data message takes 5 flits. Am I correct? Thanks, Pavan On Mon, Sep 17, 2012 at 10:04 AM, Tushar Krishna <tus...@csail.mit.edu>wrote: > Answers inline. > > On Sep 17, 2012, at 12:42 PM, Pavan Poluri wrote: > > Hello, > > I have a question on the *ni_flit_size* parameter in the file > garnet/BaseGarnetNetwork.py. From the documentation I understood that > ni_flit_size specifies the flit size in bytes. The default value is 16 > bytes. In the documentation, it says that this results in a control message > fitting in 1 flit and data message fitting in 5 flits. So this means that > the control message is 16 bytes and the data message is 80 bytes. The > following are the two questions I have: > > 1. Lets say if I change the ni_flit_size to 8 bytes, would it > automatically translate to a control message that fits in 2 flits and data > message fitting in 10 flits? > > Yes. Take a look at NetworkInterface_d.cc where number of flits are > calculated. > > 2. Are the sizes of control message (16 bytes) and data message (80 bytes) > fixed? Is it possible to modify their sizes? > > Take a look at network/Network.py/cc > > Thanks for your time. > > Thanks, > Pavan > > On Wed, Sep 12, 2012 at 2:54 PM, Pavan Poluri <poluripa...@gmail.com>wrote: > >> Thanks Tushar. >> >> Thanks, >> Pavan >> >> >> On Wed, Sep 12, 2012 at 12:23 PM, Tushar Krishna <tus...@csail.mit.edu>wrote: >> >>> ** >>> If you divide the total flits by total cycles by 16, you can see that >>> the injection rate is only 0.0009 flits/cycle/node. Hence your power is so >>> low. >>> The total network energy might be an alternate metric that you might >>> want to consider instead of power to remove cycles from the picture. >>> Take a look at src/mem/ruby/network/orion/NetworkPower.cc where the >>> energy and power calculations are done. >>> For a relative comparison, the numbers from Orion might work for you... >>> You could compare the energy numbers for each component from Orion and >>> DSENT if you want to see how much they differ. >>> >>> The cache sizes are in configs/common/Options.py >>> >>> >>> On 09/12/2012 03:26 PM, Pavan Poluri wrote: >>> >>> Hi Tushar, >>> >>> The simulation ran for 5,400,912,679 cycles. How do I reduce the cache >>> sizes? Which source files do I need to modify? >>> >>> I was also looking into DSENT tool. To the extent I understood, the >>> current version of DSENT does not model the power of the Virtual Channel >>> Allocation stage. It only models the power for buffer, crossbar, switch >>> allocator and clock. I really need to calculate the power of the Virtual >>> Channel Allocation stage. >>> >>> Thanks for your help. >>> >>> Thanks, >>> Pavan >>> >>> On Wed, Sep 12, 2012 at 10:51 AM, Tushar Krishna >>> <tus...@csail.mit.edu>wrote: >>> >>>> Hi Pavan, >>>> There are two issues here. >>>> One, as Mitch pointed out, is that Orion is not entirely accurate. >>>> I would suggest computing activity counts from garnet and feeding them >>>> to DSENT. >>>> >>>> However, I have a feeling you will see a similar phenomenon (dynamic >>>> power >> leakage power) even with DSENT. >>>> How many cycles did your simulation run for? >>>> For full system runs in gem5, the network activity is typically very >>>> low (since network gets flits only on cache misses). >>>> As a result your dynamic power is very low. >>>> Network activity can be increased by reducing cache sizes. >>>> >>>> cheers, >>>> Tushar >>>> >>>> >>>> On Sep 12, 2012, at 1:43 PM, Pavan Poluri wrote: >>>> >>>> Hi, >>>> >>>> Thanks a lot for your detailed reply. >>>> >>>> Thanks, >>>> Pavan >>>> >>>> On Wed, Sep 12, 2012 at 10:32 AM, Mitch Hayenga < >>>> mitch.hayenga+g...@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I wouldn't trust the power model. Garnet is based on Orion, which >>>>> in the last year a few papers have shown to be quite inaccurate (mostly >>>>> because its internal model doesn't scale some technology parameters >>>>> properly). >>>>> >>>>> More Information: >>>>> 1. Peh's group recently announced a more accurate power modeling tool >>>>> called DSENT (https://sites.google.com/site/mitdsent/). In their >>>>> paper they highlight many issues with Orion and (at the 45nm node) find it >>>>> capable of being off by ~10x in power. >>>>> >>>>> 2. I published a WDDD paper on Orion showing my own brief >>>>> investigation into why its power/area numbers seemed disconnected with >>>>> reality. (http://www.ece.wisc.edu/~hayenga/papers/wddd2012_hayenga.pdf >>>>> ) >>>>> >>>>> Hope this helps. Maybe the version of Orion integrated with >>>>> Ruby/gem5 has received some updates, but unless you've heard otherwise, I >>>>> wouldn't trust it. >>>>> >>>>> >>>>> On Wed, Sep 12, 2012 at 12:30 PM, Mitch Hayenga < >>>>> mitch.haye...@gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I wouldn't trust the power model. Garnet is based on Orion, which >>>>>> in the last year a few papers have shown to be quite inaccurate (mostly >>>>>> because its internal model doesn't scale some technology parameters >>>>>> properly). >>>>>> >>>>>> More Information: >>>>>> 1. Peh's group recently announced a more accurate power modeling >>>>>> tool called DSENT (https://sites.google.com/site/mitdsent/). In >>>>>> their paper they highlight many issues with Orion and (at the 45nm node) >>>>>> find it capable of being off by ~10x in power. >>>>>> >>>>>> 2. I published a WDDD paper on Orion showing my own brief >>>>>> investigation into why its power/area numbers seemed disconnected with >>>>>> reality. ( >>>>>> http://www.ece.wisc.edu/~hayenga/papers/wddd2012_hayenga.pdf) >>>>>> >>>>>> Hope this helps. Maybe the version of Orion integrated with >>>>>> Ruby/gem5 has received some updates, but unless you've heard otherwise, I >>>>>> wouldn't trust it. >>>>>> >>>>>> >>>>>> On Wed, Sep 12, 2012 at 12:07 PM, Pavan Poluri < >>>>>> poluripa...@gmail.com> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I have executed the Blackscholes application of the PARSEC >>>>>>> benchmark suite with 16 threads on the input file set (in_4.txt) with a >>>>>>> full system simulation with 16 cores, 16 L2 caches and 16 directories >>>>>>> on a >>>>>>> mesh topology with 4 rows. I have used the MOESI_CMP_directory protocol. >>>>>>> The technology used is 90nm with a clock frequency of 1GHz and operating >>>>>>> voltage VDD of 1.2V. I was going through the power statistics in the >>>>>>> ruby.stats file. The following are the power numbers from the >>>>>>> simulation. >>>>>>> >>>>>>> Router Dynamic Power = 0.00710691 W => 0.4441 mW per router >>>>>>> Router Static Power = 0.452366 W => 28.272 mW per router >>>>>>> Router Clock Power = 0.541901 W >>>>>>> >>>>>>> I am confused with these power numbers. The dynamic power is very >>>>>>> very less compared to the static power. I do not understand why the >>>>>>> dynamic >>>>>>> power is so low even when the simulation resulted in the injection of >>>>>>> 75,899,868 flits and the successful reception of 75,899,865 flits. Am I >>>>>>> doing something wrong with the simulation? Do I need to set some >>>>>>> parameters >>>>>>> for the power calculations? >>>>>>> >>>>>>> Thanks for your time. >>>>>>> >>>>>>> Thanks, >>>>>>> Pavan >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gem5-users mailing list >>>>>>> gem5-users@gem5.org >>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mitch Hayenga >>>>>> mitch.haye...@gmail.com >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> gem5-users@gem5.org >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing >>> listgem5-users@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
