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? 2. Are the sizes of control message (16 bytes) and data message (80 bytes) fixed? Is it possible to modify their sizes? 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
