Hi @dstocco, can you confirm both readout.exe and StfBuilder are built against the same version of FairMQ?
Also, please share the full log of StfBuilder and readout.exe via cernbox.
Thanks
@costaf: data looks ok from what I can see from:
/home/flp/output/readout_file.raw
But yes there is a processing in the middle (I’m decoding data on the fly). And since the FEE is off, the electronics sends lots of data (apparently the logic is inverted), and the processing becomes busy very fast.
If I remove the processing, and just try feeding the o2-dpl-parser with --log-level 0 the problem seems to disappear.
Notice that it is enough to set log-level 1 to have the issue come back…
So, sorry about it: this is my fault.
Cheers,
Diego
Hi @dstocco, ok, seems that the processing is creating back-pressure all the way up to the CRU. Error in StfBuilder indicate that the received data is not complete. We should really handle this better with some watermarks to avoid invalid data in error conditions.
One thing you could try is to add --max-buffered-stfs <N> to StfBuilder. If the downstream data consumer is too slow the StfBuilder will start dropping STFs when the specified limit is reached.
Hi @gneskovi,
thanks for the suggestion.
However I tried different values for N (1, 10, 100), but I do not see much of a difference…