Ptolemy EVM Simulation

1
Ptolemy EVM Simulation

• -evma
• The configuration focuses on
• RCN over myrinet, No extra network for RCN
  traffic. BM is connected to last leg of switch on
  RU side and RM is connected to last leg on BU
  side (see fig on next page) with no barrel
  shifter on BU side.
• Trigger
• Poisson 12.5 kHz (default), or Gaussian with
  cut-off
• BM Messages
• CMSAllocatemessage is to make an event request to
  BM
• CMSClearmessage is to send a clear request to BM
• CMSConfirmmessage is to assign event ID to BU
• RM Messages
• CMSRCNMessage is to broadcast event IDs to all RUs

2
RCN over Myrinet
3
BCN and RCN Traffic

• No packing of BCN messages
• Each BU makes a request of single event id to BM
  every time.
• RCN messages packing factor is 2
• The RCN average latency for informing all RUs is
  112 us (Plot attached), almost all of which is
  non-overlappable. Since subsequent triggers are
  separated by 80 us on average, we have to pack
  at least two RCN messages to keep up.
• Event fragments
• Lognormal distribution with 16/-16 kB/RU

4
RCN Over Myrinet

• Conclusion
• 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 Latency
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 BM 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.

7
Active Events in EVM
8
Filter Nodes

• Farm processing time (FPT)
• Lognormal distribution, values given per plot
• Each BU emulates 8 filter nodes
• Average farm processing time should not exceed 40
  ms/event
• BU returns an event ID at the end of its FPT (!)
• As soon as BU builds a complete event, it
  immediately passes that event to filter node and
  frees it memory. Upon receiving acknowledgement
  from filter node at the end of FPT, BU then sends
  a clear message to BM to clear this event. If all
  filter nodes are already busy processing event,
  BU puts this event into filter nodes queue with
  least expected time.

9
Active events in EVM, FPT 40 /- 0ms
ms
10
Active events in EVM, FPT 40/-20ms
Steady state level increase supposedly due to
queuing in filter nodes. Event with large FPT
will delay return of all following events sent to
that filter node. System will stabilize if FPT
average does not exceed 40 ms.
ms
11
Active events in EVM, FPT 40/-40ms
ms
12
Active events in EVM, FPT 30/-30 ms
ms
13
RU max. memory usage (FPT 30/-30 ms)
As long as the BUs have free resources, this is
independent of the FPT (modulo differences in
random generator usage).
ms
14
BU max. active events, FPT 30/-30 ms
ms
15
BU max. memory usage, FPT 30/-30 ms
ms
16
Active events in EVM, FPT 30/-30 ms, Event
Fragments 16 /- 16/sqrt(8) kB/RU
ms