Re: [Gems-users] Message Delayed Cycles

["Lei Yang" <lya755@xxxxxxxxxxxxxxxxxxxx>]

Thanks Mike. Should I change this parameter in order to increase the network 
bandwidth: g_endpoint_bandwidth?
Lei
----- Original Message ----- 
From: "Mike Marty" <mikem@xxxxxxxxxxx>
To: "Lei Yang" <lya755@xxxxxxxxxxxxxxxxxxxx>; "Gems Users" 
<gems-users@xxxxxxxxxxx>
Sent: Thursday, April 19, 2007 9:23 PM
Subject: Re: [Gems-users] Message Delayed Cycles


> Lei Yang wrote:
> > This guess actually is close to mine. But I'm wondering if there is a 
> > sanity check, for example, if I make the network bandwidth to a very big 
> > value, or if I use indefinite queue size, would the problem go? Because 
> > if it is, then this may not be a problem of my protocol, but a problem of 
> > Ruby configuration, because in actual hardware design, we might have 
> > bigger bandwidth or bigger queue size. Right?
> Well it certainly sounds like the increased messages are causing 
> additional queuing in the network.  If you want the problem to go away, 
> the incresae the network bandwidth.
> > Dan, how do I monitor the queuing contention?
> The delay_cycles that you are seeing exists in MSI_MOSI_CMP_directory to 
> do exactly this-- monitor queuing delays.  See of the .sm files use the 
> profileMsgDelay() whenever removing a message from the network.  I believe 
> this is the only protocol that currently profiles the delay cycles.