Dear all,
I have a question on the chain StfBuilder + dpl-raw-proxy.
I’m, running on an FLP with two GBT links enabled. I would like to send each link to a different subspec.
For the moment I’m doing it by hand, i.e.:
configure raw-proxy to send data to MID/RAWDATA
add a device that reads the MID/RAWDATA and, depending on the linkID, it sends the output to different subspecs, e.g. MID/RAWDATA/0, or MID/RAWDATA/1
I am wondering if there is already some general way to do this, without having a custom device in the middle.
The StfBuilder itself adds a subspec to the DataHeader as (RDH.cruID<<16) | ((RDH.linkID + 1)<<(RDH.endPointID == 1 ? 8 : 0));
and this subspec is relayed by the raw-proxy: the device which subscribes to MID/RAWDATA should receive MID/RAWDATA/ and MID/RAWDATA/ according to the convention above.
Do you see something different?
Hi @shahoian,
ok, thanks. I did not realise it, also because I was not retrieving the DataHeader.
So it is enough that I spawn 2 devices, each one asking for the correct MID/RAWDATA/Subspec, is it correct?
Thanks!
Cheers,
Diego
In principle, yes, but in practice current way of the StdBuild to define the subspec relies on run-time-defined RDH fields: neither RDH.cruID nor RDH.linkID are supposed to have unique mapping to the detector. This means that at the moment you cannot know a priory which subspecs to expect (in the tests, you can surely cheat since you know your CRU ids)
Hi Ruben,
ok, I see. Well, if I want to spawn different devices I guess I will have to cheat for the tests, indeed, unless there is a dynamic way to do so.
Anyways, I had a deeper look at the data, also the ones saved to file and read-out through your o2-raw-file-reader-workflow. The data (obtained w/o the CRU user logic) contains 2 links with:
a) feeId: 4844 CRUID: 0 EPID: 0 linkId: 0
b) feeId: 4844 CRUID: 0 EPID: 0 linkId: 1
Now, according to your explanation, I should expect a subspec of:
a) 0
b) 1
Instead, I get:
a) MID/RAWDATA/0x317461228
b) MID/RAWDATA/0x351015916
The first is actually: (feeId >> 16) | feeId
The second is something like ((feeId + (1<<9)) >> 16) | (feeId + (1 << 8))
So, not sure what to expect for the raw-proxy…
@dstocco Maybe @gneskovi has already modified the subspec definition? Although, I think until detectors do not define feeIDs unique for every link, making the subspec to depend on feeID does not make much sense.
The raw-proxy should keep the subspec assigned by the DataDistribution. Why don’t you dump o2-dpl-raw-proxy <settings> | o2-dpl-raw-parser --input-spec "A:MID/RAWDATA"
the raw-parser will print the received subspec.
Hi @shahoian,
thanks to the raw-parser I confirm that, in the DataHeader, the two links are sent to subspec 1 and 2, respectively, which is consistent with what what you told me here.
So, I just need to specify: o2-dpl-raw-proxy --dataspec "A:MID/RAWDATA/1;B:MID/RAWDATA/2"
and spawn 2 decoders, each one reading 1 input to get what I need.
This of course requires an a-priori knowledge of the CRUID, LinkID and EPId…but it is ok for tests.
Thanks!
Cheers,
Diego
Hi @shahoian,
There is a new option for StfBuilder: --detector-subspec where you can select the method of SubSpec generation. With cru_linkid (default) you get the old method of using cruild and link id , and with feeid the FEEID is used directly. This is currently in DataDistribution/dev branch.
This will apply only for the new readout data. STF files recorded with StfBuilder will still replay the used SubSpec method at the time of recording.
Cheers