Hello, Thanks for your reply. If the 1-flit packets of type HEAD_TAIL_ are control messages, I am unable to figure out why do we need to perform Routing Computation, Virtual Channel allocation etc computations on these HEAD_TAIL_ flits?
Thanks for your time. Thanks, Pavan On Tue, Sep 25, 2012 at 9:53 PM, Tushar Krishna <tus...@csail.mit.edu>wrote: > Yes 1-flit packets (of type HEAD_TAIL_) are control messages from the > protocol. > > - Tushar > > On Sep 25, 2012, at 8:04 PM, Pavan Poluri wrote: > > Hello, > > I have a question on the single flit packets generated when synthetic > traffic simulation is used. These 1 flit packets are of type HEAD_TAIL_. > According to the default settings, control message (8 bytes) occupies 1 > flit and a data message (72 bytes) occupies 5 flits, where each flit is 16 > bytes. My question is, > > Are these 1 flit packets of type HEAD_TAIL_ control messages or are they > something different? > > Thanks for your time. > > Thanks, > Pavan > > On Mon, Sep 17, 2012 at 1:56 PM, Pavan Poluri <poluripa...@gmail.com>wrote: > >> Thanks Tushar. >> >> Thanks, >> Pavan >> >> >> On Mon, Sep 17, 2012 at 11:49 AM, Tushar Krishna <tus...@csail.mit.edu>wrote: >> >>> Yes all that is correct. >>> >>> data msg size is 72 bytes, not 80. I will correct that on the wiki. >>> >>> cheers, >>> Tushar >>> >>> >>> On Sep 17, 2012, at 2:05 PM, Pavan Poluri wrote: >>> >>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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
