I’m running acquisitions on the FLP, using readout.exe + StfBuilder + o2-dpl-raw-proxy.
I notice that, often, the o2-dpl-raw-proxy exists automatically while the acquisition is running:
[9725:readout-proxy]: [10:39:15][STATE] RUNNING ---> READY
[9725:readout-proxy]: [10:39:15][STATE] READY ---> RESETTING TASK
[9725:readout-proxy]: [10:39:15][STATE] RESETTING TASK ---> DEVICE READY
[9725:readout-proxy]: [10:39:15][STATE] DEVICE READY ---> RESETTING DEVICE
[9725:readout-proxy]: [10:39:15][STATE] RESETTING DEVICE ---> IDLE
[9725:readout-proxy]: [10:39:15][STATE] IDLE ---> EXITING
[9725:readout-proxy]: [10:39:15][STATE] Exiting FairMQ state machine
[9725:readout-proxy]: [10:39:15][WARN] Some input data are not matched by filter rules
This of course causes the the acquisition to drop packets, since they are not consumed anymore. I cannot find out why this happens. Do you have any clue on what can trigger a stop in the proxy?
Notice also that I run the DPL proxy with:
o2-dpl-raw-proxy -b --session default --dataspec "A:MID/RAWDATA/1;B:MID/RAWDATA2" --channel-config "name=readout-proxy,type=pull,method=connect,address=ipc:///tmp/stf-builder-dpl-pipe-0,transport=shmem,rateLogging=1"
i.e., I explicitly specify the dataspec. However, the proxy warns me that the default FLP/DISTSUBTIMEFRAME/0 is unmatched. I’m not sure if this comes from the StfBuilder.
Thanks in advance for any hint,
never mind: I think I figured out the problem.
I run the different programs (StfBuilder, o2-dpl-proxy, readout.exe) in different windows using the gnu screen program.
If I switch to the tab running o2-dpl-proxy while the command has stared data acquisition, the program interprets the switch as a stop signal and exits.
Funny enough, if I switch to the tab before the data taking starts, and I wait for the acquisition to start, I can then switching tab as I like and the program does not exit anymore…
Is there a recommended way to launch an acquisition (i.e. sequential launch of the three different required processes readout + StfBuilder + dpl-proxy) on FLP?
A rule of thumb from my experience is to start the workflows in reverse order. E.g. STFSender, then DPL piped workflows, then STFB, then readout.
I believe we should be able at some point to start them all in whatever order. Not sure whom to ask though.
thanks for the info. Yes, this is also what I do: DPL workflows, then STFB and last Readout (I do not use the STFSender yet).
the exact order of starting of the processes should not matter if you use push/pull type for the channels (which it looks like you already do). If some of the tasks start pushing data already on start (as would be the case if you load data form files), then starting the tasks from the end of the chain is advised.
Can you share what your chain looks like in more detail? IIRC you need something that will ‘discard’ the data after the dpl-proxy, otherwise the dataflow will block.
this is my workflow:
o2-dpl-raw-proxy -b --session default --dataspec "A:MID/RAWDATA/1;B:MID/RAWDATA2" --channel-config "name=readout-proxy,type=pull,method=connect,address=ipc:///tmp/stf-builder-dpl-pipe-0,transport=shmem,rateLogging=1" | o2-mid-raw-checker-workflow -b --session default --bare --feeId-config-file "feeId_mapper.txt" --per-gbt
Notice that the checker is basically a sink and has no DPL output.
For what concerns the StfBuilder:
StfBuilder --session default --id stf_builder-0 --transport shmem --detector MID --dpl-channel-name dpl-chan --channel-config "name=dpl-chan,type=push,method=bind,address=ipc:///tmp/stf-builder-dpl-pipe-0,transport=shmem,rateLogging=1" --channel-config "name=readout,type=pull,method=connect,address=ipc:///tmp/readout-pipe-0,transport=shmem,rateLogging=1"
And for the readout:
# session name must match --session parameter of all O2 devices in the chain
memoryBankName = bank-o2