Hello, I figured out the answer to my question.
Thanks for your time. Thanks, Pavan On Mon, Oct 1, 2012 at 11:27 AM, Pavan Poluri <poluripa...@gmail.com> wrote: > Yes HEAD_TAIL_ is equivalent to HEAD_ without BODY and TAIL flits. So a > single control packet is like a path guider to a single data packet? Every > time a router injects a data packet into the network, it injects a control > packet to initiate the data packet injection? > > Thanks, > Pavan > > > On Mon, Oct 1, 2012 at 11:04 AM, Tushar Krishna <tus...@csail.mit.edu>wrote: > >> Why not? >> HEAD_TAIL_ is equivalent to a HEAD_ right (it just so happens that there >> are no BODY and TAIL flits in this packet). It still needs to choose a >> route, reserve a VC (a 1-flit-deep VC in this case). >> >> - Tushar >> >> >> On Oct 1, 2012, at 1:58 PM, Pavan Poluri wrote: >> >> 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 >> >> >> >> _______________________________________________ >> 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
