Re: [Gems-users] Config parameters

[Mike Marty <mikem@xxxxxxxxxxx>]

> I dont understand the meaning of these parameters and what queue/structures they represent in the system
>

I strongly suggest grepping through the code or using your favorite C/C++
cross-referencing utility.  Many of the parameters are only used for
certain configurations and protocols.


>  L2_RESPONSE_LATENCY

Used by some protocols (MOSI_MSI_CMP_directory,MOESI_CMP_directory, etc)

>  RECYCLE_LATENCY:

Some protocols "recycle" a MessageBuffer.  This is popping the message off
of a queue and re-enqueing it with the above latency.  It essentially
simulates non-FIFO queues.  Parameter is used in
$GEMS/ruby/buffers/MessageBuffer.C

>  L2_RECYCLE_LATENCY:
>  COPY_HEAD_LATENCY

Sorry, I don't recall what these are used for off the top of my head.

>  SEQUENCER_TO_CONTROLLER_LATENCY
>

The latency incurred to reach a cache controller.  In some SMP
configurations, this actually corresponds to the L2 hit latency (the SMP
protocols where each controller models both the L1 and L2 caches)


>  If i am providing the network file why do I need to specify
>  NETWORK_LINK_LATENCY
>  ON_CHIP_LINK_LATENCY
>

You don't if you are providing a network file.

>  How ruby multiplier affects simulation timing ? If we are using ruby with simics
>
>  g_think_time: 5
>  g_hold_time:  5
>  g_wait_time:  5
>

These are only used by one of the Ruby tester micro-brenchmarks.  These
parameters can be ignored.

--Mike