...

Thanks for looking into this, Chris.  The only thing I’ve been able to come up with on a quick look is that the time is maybe going into setting up the memory region for the DRP to share the event with the MEBs.  I think this is mostly libfabric manipulating the MMU for this already allocated space (the pebble).  Is the event buffer size maybe particularly large compared to the other DRPs?  I’m guessing that since it’s an Andor, maybe 8 MB?  Not sure what ‘vls’ does to it.  If the trigger rate for this DRP isn’t high (10 Hz?), we could maybe speed this step up by lowering the number of DMA buffers so that fewer MMU entries are needed.

Deadtime Issues

Default plan: high-rate detectors get L0Delay 100, low-rate detectors get L0Delay 0.

Jumping L1Count

In general, this error message is a sign that the back pressure mechanism is not working correctly and buffers are being overwritten.  L0Delay being set too small is one possible cause, but other firmware "high water mark" buffer parameters can be another.  See TriggerDelays for a discussion of L0Delay.

Buffer Management Registers

xpm

• L0delay
• the is no corresponding CuDelay for superconducting beam (because Cu system has 1ms "early notice", but superconducting has 100us of "early notice")

timing system

• matt thinks it is "pauseThr" visible in kcuSim (currently set to 10)

camlink gateway

• cpo thinks XpmPauseThresh was put in to protect a buffer of xpm messages, but could be wrong
• does this also protect the data buffers?

wave8

• FifoPauseThreshold (currently 255).  only need one register because it's configurable fixed-length

hsd

• in hsdpva "full_event" (currently 8) and "full_size" (currently 2048): these are "remaining" buffers, so when either of these ("or") drops below this value then deadtime is asserted. need two parameters because the FEX is variable length.

epixhr

• to be determined 

Timing System kcu1500 (or "sim")

...