Re: [Gems-users] Garnet Network parameters

[Niket Agarwal <niketa@xxxxxxxxxxxxx>]

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.