Project

General

Profile

Actions

Development #1519

open

Development #1510: Online software for mCBM 2020

Digi classes

Added by Volker Friese over 2 years ago. Updated 11 months ago.

Status:
In Progress
Priority:
Normal
Target version:
Start date:
02/05/2020
Due date:
% Done:

100%

Estimated time:
(Total: 10.00 h)

Description

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?


Subtasks 1 (0 open1 closed)

Development #1520: CbmStsDigiClosedVolker Friese02/05/2020

Actions
Actions #1

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
Actions #2

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.

Actions #3

Updated by Volker Friese about 2 years ago

  • Target version changed from APR20 to APR21
Actions #4

Updated by Florian Uhlig 11 months ago

What about this ticket?

Actions #5

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.

Actions #6

Updated by Florian Uhlig 11 months ago

  • Target version changed from APR21 to DEC21
Actions

Also available in: Atom PDF