Dear all,
I’m running an acquisition using the debug mode with User and Common logic enabled.
I can correctly stream the data to file(s), and in particular with one file per link.
However, when I run the StfBuilder, I get some errors/warnings:
[2020-11-05 10:02:29.689][**E**] READOUT INTERFACE: TF ID non-contiguous increase! (1) -> (11239) readout.exe sent messages with non-monotonic TF id! SubTimeFrames will be incomplete! Total occurrences: 0
[2020-11-05 10:02:29.689][D] Sending an STF out. stf_id=1 stf_size=131072 unique_equipments=1
[2020-11-05 10:02:29.689][**E**] READOUT INTERFACE: update with mismatched subspecification. block[0]: 0x0001, block[29]: 0x0010
[2020-11-05 10:02:29.689][**E**] READOUT INTERFACE: update with mismatched subspecification. block[0]: 0x0010, block[60]: 0x0001
Also, I have these warnings in the readout.exe:
2020-11-05 10:02:29.684736 ! **Warning - TF11239 link Id mismatch 0 != 15 @ page offset 8192**
2020-11-05 10:02:29.684808 ! **Warning - TF11239 link Id mismatch 0 != 15 @ page offset 16384**
So, I have two questions:
Is it normal to have a link ID mismatch? After all, in debug mode I have the same FEEID read in two links (the common one and on link 15 from the UL). Or should I expect to have no warning?
Why do I have non-contiguous TF increase? I guess that the problem is related, in the sense that I read the same FEEID from two different links (0 and 15 or 1 and 15) and, l might have an orbit change when I finish receiving the data from link 0 and I start receiving the data on the same FEEID on link 15.
Of course I’m just speculating. If you have some better explanation or a solution, please let me know.
Thanks in advance,
Cheers,
Diego
The whole machinery expects that a data page going out from the CRU belongs to a single link. The linkId mismatch warning occurs when there is mixed data from different links in one page.
TF ids are based on trigger orbit, and more specifically the one in the first RDH in each data page. It seems to report a jump from 1 to 11238… so there must be some unrealistic counters.
(but this is STF output, the exact meaning should be checked with @gneskovi).
If it’s at the very beginning, it might be some left over of previous “run”.
This was so far probably not exercised to run with UL, so there might be some situations which were not taken into account. We should probably wait @costaf to be back next week to discuss it further, I’m not familiar enough with what happens in the CRU, and it is not clear to me what should be done eg for the linkId of UL data.
Ciao,
The UL should generate link Id = 15.
Having the GBT links + UL should not create any issue, from readout point of view there is just one more link to check. Actually readout doen’t know if the data is coming from the GBT link or the UL. Readout just check the link Id coming in input.
When readout complains about the mismatch link Id 0 != 15, it looks to me that the UL is generating link Id = 0.
Just as a reminder, while for the GBT links in input the CRU will generate the link Id (from 0 to 11), for the UL it is responsibility of the UL to set the proper link id to 15 (that is a specific field in the RDH)
Ciao @costaf,
the UL is actually generating LinkId 15. Indeed, when I write on file I get 3 files, for link 0, 1 and 15.
However, after a further check I realised that:
files 0 and 15 have the expected link ID, but in the file 0 I get some HBFs coming from Link15 (!)
the UL output only has empty RDHs (it was working a couple of days ago…then we had a minor bug fix, something must have gone wrong).
We’ll focus on fixing the UL, and come back to this topic if the issue persists.
Cheers,
Diego