You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

We propose to use a two-phase approach for each transition (after CONNECT) in the DRP, inspired by the LCLS-I approach

  • The first phase is handled by a ZMQ broadcast, so configures can happen in parallel
  • The second phase is handled in the timing system thread.  This phase "sweeps" out the results from the first phase
  • The control level sends out the second phase after the first phase is completed
  • We will try to run as much code as possible in the ZMQ thread in order to make the TS thread "sweep" as quick as possible
  • The timing system thread is responsible for all xtc writing
  • If a DRP has N segment-level workers, only one of them will receive the timing system transition
  • Since the mon nodes quickly cache the relevant transition, their "completion" is ignored in this process
  • All timeouts for the two phases are done by the control level
    • each node's first-phase transition (maybe just configure and configUpdate) specifies a timeout value, perhaps with the CONNECT collection message
    • hopefully the second phase doesn't need a transition-dependent timeout, but if it does it will be specified in a similar manner to the first phase
  • The ZMQ thread should inform the timing-system thread of its config JSON, so it can be appended to the XTC
  • The timing-system thread's "complete" message is transmitted via the ZMQ thread, since that thread has knowledge of the appropriate sockets.  I think this is done with the "inprocSend" ZMQ context in DrpBase.cc.


  • No labels