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

Compare with Current View Page History

Version 1 Next »

Issue: SlowUpdate currently preempts L1Accept, so integrating detectors miss their normalization data

Requirement:

  • slowupdate data should be in time order
  • not event-built

Possible solutions:

  • do nothing: accept missing normalization data for integrating detectors
    • they could turn off SlowUpdate
  • (too hard) have L1Accept preempt SlowUpdate
    • doesn't work at 1MHz
    • some groups get SlowUpdate and others get L1Accept? want to veto the slow update for all readout groups.  Matt says this is difficult because of the usual L0Delay issue.
  • (maybe doable) eliminate SlowUpdate and add a bit to L1Accept saying "attach slowupdate data" (epics data is broadcast by psana and acts a "barrier") 
    • this perhaps feels most elegant
      • psana L1 data is unicast, SlowUpdate is broadcast
      • payloads would be identifiable somehow, as separate xtc's
        • example "broadcast" payloads: timetool background, epics data
    • biggest change
    • maybe also need a SlowUpdate without L1Accept?
    • possible implementation: new transition SlowUpdateAndL1 (in addition to SlowUpdate, L1 on their own)
      • feels like meb and psana need to split it out to a SlowUpdate and L1Accept
    • bit could be in the env or it could be a new transitionId?
    • implementation possibility:
      • we request SlowUpdate from firmware, if firmware detects no L1Accept generate SlowUpdate, if there is L1Accept firmware generates SlowUpdateAndL1
      • some readout groups will get SlowUpdate, some will get SlowUpdateAndL1 (because of the L0Delay problem): is that a problem for the event builders?
        • Ric thinks it's a problem for online eb, but maybe manageable
  • (too hard) timing system could delay SlowUpdate to the next available bucket
    • need to have all readout groups coordinate to find a commonly available bucket.  this is difficult because of L0Delay
    • this doesn't work at 1MHz (but neither do integrating detectors)
  • (ric felt might be hard) could segment levels inject broadcast data without the timing system?
    • manufacture a timestamp
      • messy to have two timestamp generators
      • use last l1accept timestamp plus 1
        • can't use pulse id plus 1 because of the 1MHz limit
      • could we use the control-level collection mechanism to distribute a common timestamp? (separate physical thread)
        • cpo worries that this is tough to do in full-flight when l1accepts are going
    • do we need to event-build the broadcast data?
      • we think no
      • psana eb, teb, meb
      • would want to treat it like an L1Accept
      • could there be, for example, a need to event build slowupdate data from a multi-segment epix detector?  like a time-time tool background?
        • background data would be staggered
        • could have an algorithm compute_bkgd=timestamp%40==0: all segments agree on when to produce new background
    • maybe give it a different transition ID: SlowL1Accept
    • Ric feels like we perhaps couldn't reuse the existing MEB slowupdate buffers for this: might be a lot of work
  • No labels