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
Maybe another idea for dealing with the L1/SlowUpdate collisions:
- Assume we'll never have a detector that adds payload to SlowUpdate timing stream data
- Payload is added at the segment level
- Let the L1Accepts have a SlowUpdate modifier bit
- Could maybe be a different transition ID, but I think that means more conditionals and will be messier
- If this bit is set:
- The DRPs handle the L1A as usual
- The DRPs look up a transition buffer using the L1A's pebble index and fills it in with the SlowUpdate data
- The SlowUpdate EbDgram has the same pulseId, etc. as the L1A but its timestamp will be the L1A's incremented by 1 ns for psana EB
- EbReceiver checks this bit and if set:
- Writes out the L1Accept
- Looks up the SlowUpdate dgram in the transition pool using the L1A's pebble index and writes it out
- psana sees two independent events, an L1Accept and a SlowUpdate, each with a separate timestamp, and handles them as currently
- Only the L1A with the SU modifier bit set is forwarded to the TEB
- Is it okay that the TEB doesn't get SlowUpdate trigger input data?
- Perhaps such input data could possibly be included in the associated L1's payload
- There is possibly no room in the batch for the SlowUpdate at 1 MHz
- Is it okay that the TEB doesn't get SlowUpdate trigger input data?
- If the bit is not set:
- The DRPs handle the L1As as usual
- If there is no collision, SlowUpdate is generated and handled as usual
- Since these can occur in slow RoGs when the fast RoG gets L1SU, the slow RoGs need to increment the timestamp so that psana can event build
- For all SlowUpdates, OK to unconditionally increment the timestamp by 1 ns?
- Feels a bit kludgy
- Maybe store the transition ID and/or group in the lower timestamp bits?
- The TEB would need to be changed so that slow RoG SlowUpdates are built with L1As having the SlowUpdate bit set
- Probably not a big modification as the pulse ID build happens naturally and only consistency checks need to be adjusted
- The MEB changes might be minimal?
- The EB is shared between TEB and MEB
- Unlike for the TEB, L1As and SUs would need to be built separately, despite sometimes having the same pulseId
- Maybe avoid the conflict by vetoing the monitor trigger request in the TEB if the L1A has the modifier bit set?
- The MEB would then receive both L1As and SUs, none with the same pulseId
- In any case buffer handling for the 3 cases should not be an issue
Overview
Content Tools