Ptolemy EVM Simulation

1
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

2
RCN Over Myrinet
3
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 IDs to
  BUs.
• RM Messages
• CMSRCN message is for broadcasting event ids to
  all read out units.
• Each BU has 256 resources. So at startup each BU
  makes a request of 256 event ids to BM in a
  single barrel shifter cycle. Upon each trigger,
  BM puts event ids in its output queue and these
  events ids are delivered to all readout units in
  each barrel shifter cycle. Also BM serves these
  event ids to BUs 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 ids to next BU. There is
  one draw back in this configuration, if a BM is
  serving event ids to a particular BU, all other
  BUs will be waiting for event ids. This makes
  the system inefficient in the beginning.

4
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).

5
RCN Over Myrinet
6
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 BUs which make data request to RUs. 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 BUs are waiting for the event ids.
  In other words they are sitting idle. Once all
  BUs becomes functional, they start building
  events and this curve comes down significantly
  low level.

7
Active Events is EVM With 0 FTP
8
Single event request and FPT is 40 ms

• Instead of making 256 event ids 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 IDs 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.

9
Single request per BU