- 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
Overview
Content Tools