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

[Weber, Guenter Dr.]

Dear Håkan,


thank you for the quick reply.


The SIS3316 modules are digitizers which we not only want to use for recording pulses from the detector (trigger type 1), but also for monitoring the baseline behaviour of the signal (trigger type 2). For type 1 we look into the metadata of each SIS3316 channel and only read out the 2^14 samples of the detector signal trace if there is a pulse (indicated by the flag in the metadata). For type 2 we would like to avoid this selection and readout all the traces.



Best greetings

Günter




----------------

Günter Weber

Helmholtz-Institut Jena
Fröbelstieg 3
07743 Jena
Germany
Phone: +49-3641-947605
www.hi-jena.de<http://www.hi-jena.de>

GSI Helmholtzzentrum für Schwerionenforschung
Planckstrasse 1
64291 Darmstadt
Germany
www.gsi.de<http://www.gsi.de>
________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Dienstag, 8. April 2025 11:23:07
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] dropping of data to analysis that cannot keep up


Dear Günter,

nice to hear from you!

The f_user function would get the trigger, so you should see it at least
there.

How to get that into nurdlib I think is a question for Hans...

Curiosity: in what way do you want to do a different readout depending on
the trigger that happened?


I also think the SIS3316 code modifications you had have been merged.

Could you please try the current version and see if that works?

Best regards,
Håkan





On Tue, 8 Apr 2025, Weber, Guenter Dr. wrote:

>
> 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/62a29ed6/attachment-0001.html>