Open pavel1murat opened 8 months ago
the problem is reproducible, starts 35 min into the run
------------------------------------------------------------------------------
%MSG-i tracker_vst_BoardReaderCore: Early 20-Dec-2023 12:23:28 CST pre-events BoardReaderCore.cc:226
Completed the Start transition (Started run) for run 105187, timeout = 600, timestamp = 18446744073709551615
%MSG
%MSG-i tracker_vst_CommandableInterface: Early 20-Dec-2023 12:23:28 CST pre-events Commandable.cc:89
Start transition complete
%MSG
%MSG-i tracker_vst_FragmentBuffer: Early 20-Dec-2023 12:23:35 CST pre-events FragmentBuffer.cc:846
Copying 1 System Fragments into output
%MSG
... snip...
%MSG-i tracker_vst_FragmentBuffer: Early 20-Dec-2023 12:58:38 CST pre-events FragmentBuffer.cc:846
Copying 1 System Fragments into output
%MSG
%MSG-w tracker_vst_FragmentBuffer: Early 20-Dec-2023 12:58:41 CST pre-events FragmentBuffer.cc:292
Bad Omen: Data Buffer has exceeded its size limits. (seq_id=2973615, frag_id=11, frags=1001/1000, szB=480480/1048576000), timestamps=2973615-2974615
%MSG
.. snip...
------------------------------------------------------------------------------
it looks that this diagnostics happens when artdaq loses events in communication between the processes
I'm running an artdaq job with the boardreader getNext function returning two artdaq fragments , both of fixed length, one with the data payload of 4 bytes and another one with the data payload of about 50*8 bytes.
About 30 min into the data taking run, artdaq starts complaining about something it calls "Bad Omen" - see below.
How does one deal with that ?
I'm using the v2_07_00_e28_s126 ots bundle compiled in debug mode, the full boardreader FCL is attached below.
-- thanks, Pasha
here is the full tracker_vst.fcl : tracker_vst_fcl.txt