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
- this perhaps feels most elegant
- (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
- manufacture a timestamp
Overview
Content Tools