• mon event builders will have two or three queues:
    • events
    • transitions (large enough to be "reliable")
    • occurrences (large enough to be "reliable")
  • transitions will be persisted so shmem readers can be restarted and get back to the correct state
  • we will try to reuse the existing shmem code
  • since performance requirements are not as extreme for monitoring, trading performance for some code simplification can be worthwhile
  • mon nodes will send an "event buffer" available command to the mon/trg event builders in a round-robin fashion
  • mon/trg event builders will keep a queue of available buffers and include this information when deciding if an event should be monitored
  • mon-nodes should be in the transition stream going back to the control level to ensure that the transitions have been received by them (although not necessarily by the user-application on the output-end of the shmem)
  • drp nodes that want to "broadcast" info to all mon nodes (e.g. timetool background, slow epics information) will send their information to the mon node whenever:
    • the mon node is elected to receive an event, and optionally as an optimization,
    • the drp node determines that the mon node has not received the information previously
  • proposed transitions:
    • config
    • beginrun
    • configupdate
    • enable
    • l1accept
  • No labels