Development #1510: Online software for mCBM 2020
The current digi classes will be used for online data processing. Their size thus matters, since the unpacking will increase the data volume to be held in memory by factors w.r.t. packed data in the time slice.
A revision of the digi classes shall remove unnecessary information, optimise the internal data representation and remove inheritance from TObject and, possibly, CbmDigi (the latter to avoid the virtual table entries).
This can probably not be achieved for the coming beamtime or for APR20, since it has large implications also on the simulation software. Neverthelesse, we should keep it in mind. For non optimised classes, we have to adjust the size of the time slices in order not to exceed the memory consumption after unpacking.
Let us start with a survey of the current status. In the table below, I list the current sizes of the digi classes (obtained by sizeof()) compared to their packed representation in the raw data messages.
System Message size (B) Digi size (B) Digi class MVD ? 88 CbmMvdDigi STS 4 32 CbmStsDigi RICH ? 40 CbmRichDigi MUCH ? 32 CbmMuchDigi TRD ? 32 CbmTrdDigi TOF ? 32 CbmTofDigi PSD ? 40 CbmPsdDigi
Pierre-Alain: Can you complement the table with the message sizes known to you?
Updated by Pierre-Alain Loizeau over 2 years ago
I updated MUCH and TOF.
One thing to remember however is that the messages are context dependent as we save bandwidth by sending common information in other message types, so comparing the size of the message to the size of the digi is somehow misleading.
For example in the STS case, the full time is obtained from the HIT message + the TS_MSB message + part of the Microslice header. The same thing is true for the mapping which is obtained from a combination of the channel and link indices in the HIT message + the source ID in the Microslice header.
In the end it all comes down to whether we want to have context free digis or to be relying on context headers that we would then need to define (e.g. a Timeslice header would allow to shave bits from the full time of the digis but would need a careful definition of digi time to avoid troubles like under/overflow when applying time offsets during calibration).
System Message size (B) Digi size (B) Digi class MVD ? 88 CbmMvdDigi STS 4 32 CbmStsDigi RICH ? 40 CbmRichDigi MUCH 4 32 CbmMuchDigi TRD ? 32 CbmTrdDigi TOF 8 32 CbmTofDigi PSD ? 40 CbmPsdDigi
Updated by Volker Friese over 2 years ago
I did not mean that necessarily, the size of the digi has to be equal to the size of the message. However, it should not exceed it by large factors, if we want to have a full time slice in memory during reconstruction.
"Context-free" means in my view that the information shall not depend on other data pieces on the same level. It does not mean that we have to store the time in ns since Christi Natum.
It is reasonable, I think, that the time of the digis is stored in context of (relative to) the current time slice. I can imagine no reason why this should not be sufficient, since we do not plan interaction between time slices. So, the "dynamic range" of the time coordinate is the length of a time slice - maximum 1s or so. Assuming 1 s in ns precision is 10^9 possible values or 30 bits.
Updated by Pierre-Alain Loizeau 11 months ago
I guess it will have to be revised once the new data format for the CRI will be know.
Maybe we can ask the detector groups already having an almost fully updated design (PSD, RICH, maybe TRD soon) to provide their expansion factor per microslice and/or timeslice, which is more representative than comparing single data units as it takes into account the context decoding/recompression done in the unpacker.
Dominik may also have a way to do something similar with the "new" STS unpacker & monitor.
In any case the issue should be re-assigned to somebody else.