# Presentation: 697544

## Ptolemy EVM Simulation

**EVMB**
**This configuration focuses on**
- RCN over myrinet with barrel shifter on both sides of switch.
- BM is connected to last leg on RU side of switch and RM is connected to last leg on BU side of switch (see fig on next slide).
- Event fragment size is 16K fixed.
- Trigger rate is 12.5
- Filter nodes
**Gaussian distribution with cut off**
**  **

## RCN Over Myrinet

## Mode of Operation

**BM Messages**
*CMSBMControl message is  for making new event request as well as  releasing event ID back to BM. There is  one flag which differentiate these messages.*
*CMSConfirm message is for assigning event ID’s to BU’s.*
**RM Messages**
*CMSRCN message is for broadcasting event id’s to all read out units.*
***Each BU has 256 resources. So at startup each BU makes a request of 256 event id’s to BM in a single barrel shifter cycle. Upon each trigger, BM puts event id’s in its output queue and  these events id’s are delivered to all readout units in each barrel shifter cycle. Also BM serves these event id’s to BU’s in batches. So BM keeps assigning these event batches to a particular BU until it has no more free resource left. Then BM starts serving event id’s to next BU.  There is one draw back in this configuration, if a BM is serving event id’s to a particular BU, all other BU’s will be waiting for event id’s. This makes the system inefficient in the beginning.  ***
**	****	****	****	**

## RCN Over Myrinet

***Our results clearly indicates that we can easily accommodate RCN traffic over the same myrinet network (250MB/s)  which is being used for BCN and BDN. In this way we can avoid an extra network for RCN ( see next slide for RCN latency plot). ***

## RCN Over Myrinet

## Active Events in EVM

***The plot on next slide shows the total number of active events in EVM without any involvement of  filter nodes. We increment this total in RM on each arriving trigger. These event are assigned to BU’s which make data request to RU’s. As soon as a particular BU builds a complete event, it immediately sends a clear request to BM to clear this event id and clear its resource. The active number total is decremented each time when BM receives a clear event request from any BU.***
***The plot on next slide shows the total number of active events in the system. We see this level goes up more than 7000 events and then comes back down and settles to less than 100 events. We understand that the reason of this build up is due to inefficiency of the the system in the beginning as BU’s are waiting for the event id’s. In other words they are sitting idle. Once all BU’s becomes functional, they start building events and this curve comes down significantly low level.   ***

## Active Events is EVM With 0 FTP

## Single event request and FPT is 40 ms

***Instead of making 256 event id’s request in the beginning, if each BU makes a request of single event ID, then other builder units will not have to wait long for event ID’s and the situation would be different. The build up in the beginning will be for very small time interval and system would  become stable very quickly. The plot on next slide shows the result with single event request in the beginning from each BU.  In this plot there is also 40ms farm processing time included.***

## Single request per BU