Arch soft dudaq trigger¶

Fact with multithread evaluation for trigger¶

To implement the level 1 trigger (or T2), 2 important things: good management of possible data saturation, i.e. the case where the calculation resource is insufficient to process all the events with the l1 trigger, a feedback of alert is necessary with for example the number of events lost per second. Secondly the use of the 2 CPUs, Tensorflow Lite has a multithreaded inference mode which is not efficient I observe a calculation gain of ~ 25% with 2 CPUs compared to the time with 1 CPU. By launching 2 inferences in parallel, the calculation time is identical to one. These specific developments are independent of the trigger method. For example it would be a mistake to implement data preparation at this level, which can be trigger method dependent.

Real-time diagram legend¶

Actual architecture¶

Proposition to include trigger with full use of 2 CPU by thread¶

I propose to create one thread per CPU for event evaluation, it is 2 threads are permanent, there is no question of creating and destroying ~1000 threads per second....