Re: [Gems-users] Message Delayed Cycles

["hongxia sun" <sunhx.seraph@xxxxxxxxx>]

Hi Lei,

 

You can use open debug as GEMS/README.debugging said and open "-n" to debug network. When I debug the ruby network I trace in this way. However, in this way, the info is too much.

If the problem is as Dan and Mike said, you can add a debug info in GEMS/ruby/network/Throttle::wakeup() function which is used to do the flow control. In this function, If a msg cannot get enough bandwidth to throttle, it will register itself in EventQueue with one cycle delay so that it can be transferred next cycle. You can add print info when the msg is rescheduled to see whether there are too many msgs rescheduled because of lack of bandwidth.

 

Regards,

Hongxia
 

2007/4/20, Lei Yang <lya755@xxxxxxxxxxxxxxxxxxxx>:

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?

 

Dan, how do I monitor the queuing contention?

Hongxia, how could I tell where the delay is by printing out debug info? Did you mean to look at the transition trace?

 

Thanks for your advice,

 

Lei

----- Original Message -----

From: Dan Gibson

To: Lei Yang ; Gems Users

Sent: Thursday, April 19, 2007 8:58 PM

Subject: Re: [Gems-users] Message Delayed Cycles

 

The only thought I can offer is that your change significantly affected the queuing contention for various links in the topology (wild guess).

Lei Yang wrote:

Dear list,

 

I noticed that after I made some change to the MSI_MOSI_CMP_directory protocol, the network delay cycles were significantly increased.

 

Below I'm pasting the virtual network 1 delay cycles of unmodified protocol and modified protocol. (Virtual network 1 is the network that connects the local l2s to the directory).

 

unmodified:

virtual_network_1_delay_cycles: [binsize: 1 max: 15 count: 330763 average: 1.18152 | standard deviation: 2.62497 | 274530 2 18 249 191 181 64 172 54618 276 116 23 38 9 29 8 41 ]

modified:

virtual_network_1_delay_cycles: [binsize: 4 max: 194 count: 289410 average: 9.86392 | standard deviation: 27.4408 | 216910
45290 453 237 12 49 34 41 40 447 44 54 48 43 70 29 110 87 76 119 85 34 11754 246 568 11396 230 894 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 ]

Could anyone please tell me what is the dominant factor of message delay cycle?  For example, I changed the DIRECTORY_TRANSITION_PER_RUBY_CYCLE parameter from 32 to 256 in rubyconfig.defaults . Because my modifications introduced more message sent to the directory and I thought the number of requests that can be handled by the directory  in one cycle matters. However, this doesn't help at all. I would really appreciate any hint from you. Thanks in advance!

 

Lei

_______________________________________________
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.