Versions Compared

Old Version 2

changes.mady.by.user Christopher O'Grady

Saved on

compared with

New Version 3

changes.mady.by.user Christopher O'Grady

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 both phases immediatelythe second phase after the first phase is completed
  • We will try to run as much code as possible The FSM runs in the ZMQ thread , except for event(), which runs in the timing system thread
  • All other code in the timing-system thread (apart from event()) should not be detector-specific
  • 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
  • The completion of the first phase of the transition is "hidden" from the control level (i.e. it only sees the completion of the second phase)
  • 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
    For each non-event transition:
    • the timing thread waits for a result from the ZMQ thread, with optional JSON that should be appended to the output xtc
    • each transition (maybe just configure and configUpdate) specifies a timeout value, perhaps with the CONNECT collection message
    • timeouts are used by
      • the timing-system thread to timeout the message from the corresponding ZMQ thread
      • the control level to timeout the responses from the various DRP timing system threads.  we believe the control level can set the value to the maximum of all the timeout values (plus overhead)

In this diagram the ZMQ threads are on the left and the timing system (TS) threads are on the right.

  • "SegWork" is a segment-level worker thread (one of many)
  • "Eb" corresponds to the infiniband event-builder
  • "EbRcvr" corresponds to the thread in the DRP node that receives the dgram response from the Eb.

 

    • 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 TS thread of its config JSON, so it can be appended to the XTC

 

Image AddedImage Removed