Re: [Gems-users] ruby parameter selection

[Mladen Nikitovic <mladen@xxxxxx>]

Thanks for the tip!

I used grep in the generated MOESI_CMP_directory directory and found the 
following variables used in various C-files.
PROTOCOL_BUFFER_SIZE
PROCESSOR_BUFFER_SIZE
FINITE_BUFFERING
L2_REQUEST_LATENCY
L1_REQUEST_LATENCY
DIRECTORY_LATENCY
L2_RESPONSE_LATENCY
L2_CACHE_NUM_SETS_BITS
L2_CACHE_ASSOC
L1_CACHE_NUM_SETS_BITS
L1_CACHE_ASSOC
PROTOCOL_DEBUG_TRACE

The problem is that I'm pretty sure these are not all of the variables 
that are used in the protol. For instance, RUBY_MULTIPLIER is for sure 
used, but it does not show up when using grep (except in the config.h).
I expected the variable MEMORY_RESPONSE_LATENCY_MINUS_2 to be used, but 
it's not. Does this mean that this protocol does not model a main memory?
What I want to achieve is an understanding of the timing model used in 
MOESI_CMP_directory protocol, a mapping between the configuration 
variables and the timing model implemented in ruby. I have used gdb/ddd 
with breakpoints to follow the execution flow, but it does not show how 
the time advances in a clear way. I have also used the DEBUG_ENABLE flag 
to generate debugging output. That helped me somewhat but it is still 
hard to pinpoint where the delays of the caches, directories, the 
network, and the main memory are calculated and used.
Is there any other approach that you think is better?

/Mladen


Dan Gibson wrote:
> Most of the timing variables are protocol-dependent, unfortunately.
> Grep through MOESI_CMP_directory to discover which variables it uses, 
> and how. I'm no expert on that protocol, so I cannot answer your 
> question directly.
> Regards,
> Dan
>
> Mladen Nikitovic wrote:
>   
> > Hi,
> >
> > I would like to model a pretty simple system with a L1 cache that has an 
> > access time of 1 cycle and an L2 access time of 6 cycles + latency of 
> > the network.
> > I have a problem with setting up these parameters in ruby, especially 
> > the L1 latency.
> > There are many parameters that seem related but it seems some are used 
> > in some protocols, not all.
> > I'm using the MOESI_CMP_directory protocol.
> >
> > I managed to reduce the execution time of the application by changing 
> > the ruby_mutliplier from 2 to 1.
> > The parameters that I'm hesitating about regarding cache latency are the 
> > following:
> > DIRECTORY_CACHE_LATENCY - value: 6 - this latency is used when accessing 
> > the L2, right?
> > ISSUE_LATENCY - value: 2 - what type of issue is this? where is this 
> > issue performed?
> > CACHE_RESPONSE_LATENCY - value: 12 -  Is this L1 or L2? Is it used in 
> > MOESI_CMP_directory protocol?
> > L1_RESPONSE_LATENCY - value: 1 - used in MOESI_CMP_directory?
> > L2_RESPONSE_LATENCY - value: 6 - used in MOESI_CMP_directory?
> >
> > RECYCLE_LATENCY - value: 3 - when is recycling performed?
> > L2_RECYCLE_LATENCY - value: 5 - when is recycling performed?
> >
> > L1_REQUEST_LATENCY - value: 1 - what is the difference between REQUEST 
> > and RESPONSE?
> > L2_REQUEST_LATENCY - value: 6 - what is the difference between REQUEST 
> > and RESPONSE?
> > SEQUENCER_TO_CONTROLLER_LATENCY- value: 4 - should this be 1 or can I 
> > put it to 0?
> > One general question is whether I need to assign 0 to any of these 
> > values to achieve my objective.
> > Hope you have the time to sort out the meaning of these parameters.
> >
> > Regards,
> > Mladen
> >
> > _______________________________________________
> > 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.
> >
> >
> >   
> >     
>