Re: [Gems-users] Garnet Network parameters

["Arseniy Vitkovskiy" <arseniy.vitkovskiy@xxxxxxxxx>]

Hi Niket,

I reschedule the link for the next cycle if linkBuffer is not empty and
there are no outgoing flits (please, see the code below). However, I
checked the traces and I saw that several last flits are lost. Maybe
this happens when link rescedulings for the flits that are waiting in
the source queue are overlapped? Could you suggest a solution?

void NetworkLink_d::wakeup()
{
	if(link_srcQueue->isReady())
	{	    
	    if (linkBuffer->isEmpty() ||
		linkBuffer->isReady())
	      {
		  flit_d *t_flit = link_srcQueue->getTopFlit();
		  t_flit->set_time(g_eventQueue_ptr->getTime() +
m_latency);
		  linkBuffer->insert(t_flit);
		  g_eventQueue_ptr->scheduleEvent(link_consumer,
m_latency);
		  m_link_utilized++;
		  m_vc_load[t_flit->get_vc()]++;
	      }
	    else 
	      {
		  g_eventQueue_ptr->scheduleEvent(this, 1);
	      }
	}
}

Another thing is that the source queue grows infinitely because flits
arrive in the source queue every cycle but they leave it ever N cycles
(where N is downstream link latency).

Therefore, the router pipeline must be paused (I think, during SA
stage). In my opinion the pipeline should be paused at SA stage if
either of the two following points is true:

1) The source queue of the output link is full, OR
2) There is only one emty place in the source queue AND there is one
flit at ST stage AND there is no flit which is going to leave the source
queue next cycle.

There is a function which manages transition from SA to ST stage: void
SWallocator_d::arbitrate_outports(). Probably the changes should be
implemented here.

Could you please comment about this pipeline pausing mechanism and how
it can be implemented.

Kind regards,
Arseniy.
 

> -----Original Message-----
> From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
> bounces@xxxxxxxxxxx] On Behalf Of Niket Agarwal
> Sent: Friday, March 26, 2010 5:17 PM
> To: Gems Users
> Subject: Re: [Gems-users] Garnet Network parameters
> 
> I think the link can reschedule itself the next cycle by something
> like g_eventQueue_ptr->scheduleEvent(this, 1).
> 
> On Mar 26, 2010, at 5:17 AM, Arseniy Vitkovskiy wrote:
> 
> > Hi Niket,
> >
> > I have similar problem. I performed the linkBuffer checking and now
I
> > need to reschedule the link to the next cycle. How should I do that?
> >
> > Kind regards,
> > Arseniy.
> >
> >
> >> -----Original Message-----
> >> From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
> >> bounces@xxxxxxxxxxx] On Behalf Of Niket Agarwal
> >> Sent: Thursday, October 15, 2009 6:58 AM
> >> To: Gems Users
> >> Subject: Re: [Gems-users] Garnet Network parameters
> >>
> >> You should check if the linkBuffer is empty or has a flit which
will
> >> leave this cycle. You are checking the link_srcQueue!
> >>
> >> If neither of the condition is true, which means that no flit is
> >> being
> >> picked up form the link_srcQueue, I think you would also need to
> >> reschedule the link the next cycle.
> >>
> >> -Niket
> >>
> >> On Oct 14, 2009, at 11:16 PM, Edward Lee wrote:
> >>
> >>> Thanks for the tip. I followed the guidelines as suggested in the
> > link
> >>> and came up with the following. Anything I am missing?
> >>>
> >>> void NetworkLink_d::wakeup()
> >>> {
> >>>   if(link_srcQueue->isEmpty())
> >>>   {
> >>>       flit_d *t_flit = link_srcQueue->getTopFlit();
> >>>       t_flit->set_time(g_eventQueue_ptr->getTime() + m_latency);
> >>>       linkBuffer->insert(t_flit);
> >>>       g_eventQueue_ptr->scheduleEvent(link_consumer, m_latency);
> >>>       m_link_utilized++;
> >>>       m_vc_load[t_flit->get_vc()]++;
> >>>   }
> >>>   else
> >>>   {
> >>>       flit_d *t_flit = link_srcQueue->getTopFlit();
> >>>       if((t_flit->get_time()) <= (g_eventQueue_ptr->getTime()))
> >>>       {
> >>>           t_flit->set_time(g_eventQueue_ptr->getTime() +
> > m_latency);
> >>>           linkBuffer->insert(t_flit);
> >>>           g_eventQueue_ptr->scheduleEvent(link_consumer,
> > m_latency);
> >>>           m_link_utilized++;
> >>>           m_vc_load[t_flit->get_vc()]++;
> >>>       }
> >>>   }
> >>> }
> >>>
> >>> -- Ed
> >>>
> >>> On Wed, Oct 14, 2009 at 7:52 PM, Niket Agarwal
> >>> <niketa@xxxxxxxxxxxxx> wrote:
> >>>> You can model lower bandwidth links as you said. Please follow
> >>>> https://lists.cs.wisc.edu/archive/gems-users/2009-April/
> >>>> msg00076.shtml
> >>>>
> >>>> -Niket
> >>>>
> >>>> Edward Lee wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I would like to verify the meaning of some simulation parameters
> > to
> >>>>> come up with realistic network parameters.
> >>>>> I am running a 2GHz serengeti machine with 16 processors using
> >>>>> MOESI_SMP_directory protocol to simulate a 16-core CMP with
> > private
> >>>>> caches.
> >>>>>
> >>>>> Here are some configuration values:
> >>>>>
> >>>>> SIMICS_RUBY_MULTIPLIER: 4 --> does this mean Ruby clock is
2GHz/4
> >>>>> = 0.5GHz?
> >>>>>
> >>>>> network is 4x4 MESH via GARNET
> >>>>> g_FLIT_SIZE: 16
> >>>>>
> >>>>> a snapshot of network parameters:
> >>>>>
> >>>>> ....
> >>>>>
> >>>>> ext_node:L1Cache:0 int_node:0 link_latency:1
> >>>>> ext_node:Directory:0 int_node:0 link_latency:4
> >>>>> int_node:0 int_node:1 link_latency:8 link_weight:1
> >>>>>
> >>>>> ...
> >>>>>
> >>>>> So, since FLIT_SIZE refers to bytes/cycle and it is suggested to
> >>>>> tune
> >>>>> the latencies for lower bandwidths. Would it be accurate to make
> > the
> >>>>> following assumtions?
> >>>>>
> >>>>> 16 bytes/cycle * 0.5 Ghz / link_latency = link_bandwidth
> >>>>>
> >>>>> Accordingly,
> >>>>>
> >>>>> bandwidth to caches 8GB/s, bandwidth to memory/directory 2 GB/s,
> >>>>> bandwidth between cores is 1GB/s
> >>>>>
> >>>>> Thanks for any input in advance,
> >>>>>
> >>>>> Ed
> >>>>> _______________________________________________
> >>>>> Gems-users mailing list
> >>>>> Gems-users@xxxxxxxxxxx
> >>>>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >>>>> Use Google to search the GEMS Users mailing list by adding
> >> "site:https://lists.cs.wisc.edu/archive/gems-users/
> >>>>> " to your search.
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Gems-users mailing list
> >>>> Gems-users@xxxxxxxxxxx
> >>>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >>>> Use Google to search the GEMS Users mailing list by adding
> >> "site:https://lists.cs.wisc.edu/archive/gems-users/
> >>>> " to your search.
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Gems-users mailing list
> >>> Gems-users@xxxxxxxxxxx
> >>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >>> Use Google to search the GEMS Users mailing list by adding
> >> "site:https://lists.cs.wisc.edu/archive/gems-users/
> >>> " to your search.
> >>>
> >>
> >> _______________________________________________
> >> Gems-users mailing list
> >> Gems-users@xxxxxxxxxxx
> >> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >> Use Google to search the GEMS Users mailing list by adding
> >> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your
search.
> >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/
> > " to your search.
> >
> 
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.