Dispatch raw data to different subspaces according to link ID

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.

Thanks in advance for any hint,

Hi @dstoccom

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?

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)

With the introduction of the RDHv6 we will have detector source and feeID uniquely mapped on the particular detector and the StfBuilder will use as the origin and subspec this source and feeID respectively, see https://indico.cern.ch/event/902411/contributions/3798521/attachments/2008186/3354519/O2_Report_Identification_of_sources_for_ALICE_data.pdf

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.

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.