> On July 29, 2015, 8:56 p.m., Andreas Hansson wrote:
> > It would be great if we can add a Param.MemoryBandwdith parameter for each 
> > direction of the link, and a basic overhead parameter for how many bytes we 
> > tack on the packet. Then we could quite easily create a throughput limiter 
> > when scheduling the next packet.
> 
> Andreas Hansson wrote:
>     Any chance of getting this sorted? It would be a very valuable 
> contribution.

Sorry for my late response. Please see my comments below.


> On July 29, 2015, 8:56 p.m., Andreas Hansson wrote:
> > src/mem/serial_link.cc, line 161
> > <http://reviews.gem5.org/r/2993/diff/2/?file=48541#file48541line161>
> >
> >     One general observation here is that this only models latency, and not 
> > throughput. Would it not make sense to also model throughput "properly"?

If we take a look at the whole system, we will see that from the performance 
point of view, all the following parameters have been modeled:
- latency of the serial links (modeled by link_latency)
- bandwidth of the serial links (modeled by link_frequency)
- packetization overhead added by the serial links (modeled by link_overhead)
However, as you have noticed, only latency is modeled in SerialLink, while 
bandwidth and packet overhead are modeled in the HMCController class.

Since, HMCController is responsible for packetization and conversion of host 
transactions to HMC packets, then modeling packetization overhead in it makes 
sense.
For bandwidth, I agree that it should be modeled inside the SerialLink itself. 
But, since I have used Bridge as my reference for implementation of the 
SerialLink and Bridge cannot model bandwidth, I have used the already available 
functionality inside HMCController (which is inherited from XBar) to model 
bandwidth (Each master port of the HMCController class deliveres a maximum 
bandwidth equal to the nominal bandwidth of a serial link).

To summarize, the functionality (latency, bandwidth, overhead) is correct, but 
bandwidth is modeled in HMCController rather than the SerialLink itself.
I hope that this makes sense.


- Erfan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2993/#review6861
-----------------------------------------------------------


On July 29, 2015, 11:07 a.m., Erfan Azarkhish wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2993/
> -----------------------------------------------------------
> 
> (Updated July 29, 2015, 11:07 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 10937:c0e250c41c52
> ---------------------------
> Serial Link model for the HMC
> 
> 
> Diffs
> -----
> 
>   src/mem/SConscript acd48ddd725f 
>   src/mem/SerialLink.py PRE-CREATION 
>   src/mem/serial_link.hh PRE-CREATION 
>   src/mem/serial_link.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/2993/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Erfan Azarkhish
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to