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
