[subexp-daq] dropping of data to analysis that cannot keep up

[Weber, Guenter Dr.]

Dear friends,


sorry for coming up with a very basic question: How can I define different trigger types and make the readout procedure of a specific module dependent on the type of trigger?


Example:

I have two different trigger types, 1 and 2. To let the DAQ know, which type of trigger I have, they are plugged to the input channels 1 and 2 of our VOLUM4B. Now I would like to know in the readout of the SIS3316 module, which type triggered the current event. How do I do this?



Thank you very much!




Best greetings from Jena

Günter



P.S. As I got distracted by some hardware issues in the lab, we did not have a proper hand-over of our modifications of the SIS3316 code in Nurdlib. Did you in the meantime took over these modifications into the main branch or how is the situation?



________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Sonntag, 16. Februar 2025 11:33:35
An: Bajzek, Martin
Cc: Hubbard, Nicolas James Dr.; subexp-daq at lists.chalmers.se
Betreff: [subexp-daq] dropping of data to analysis that cannot keep up


Hi,

when the point of DAQ being faster than online is reached, we face the
issue of somehow dropping old data.

Left with default settings, ucesb is not really helpful.  Old data will
pile up in the '--server' until that is full, and only then dropped.  If
the server is configured with a large amount of memory for buffers
('--server' option 'size='), this can be significant.  This leads to
online analysis lagging reality, loosing the 'online' feeling and useful
rapid feedback of changing conditions...

There is a 'dropold=N' (seconds) option which will not serve buffers to
the client older than the specified time.  It may be reasonable to set
this to at most two times the spill length, if the beam has a pulse
structure.  Otherwise a few seconds ought to be enough.


A dry-run demo (3 instances), using the 'mbuffer' program to limit rates:

---

# Generate data (at 10 MB/s):

file_input/empty_file --lmd \
   | mbuffer -r 10M -q \
   | empty/empty --file=- --server=trans,size=1G

# Serve the data, with dropold (can be removed):

empty/empty --trans=localhost --server=trans:8000,size=1G,dropold=10s

# 'Analysis' (at 1 MB/s).
# Look at the data (buffer times)
# Note: dd is used here to strip the 16-byte transport protocol startup
# message.

nc localhost 8000 \
   | mbuffer -r 1M -q \
   | dd bs=16 skip=1 \
   | empty/empty --file=- --print-buffer

---

Note: the buffer times only relates to the middle server, not the original
data generation.  But in this case is good enough to show the difference.
If 'dropold' is not used in the middle instance, then the last instance
(doing --print-buffer) will be seen to lag further and further.


Cheers,
Håkan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20250408/d8196459/attachment.html>