I am doing further tests of the QC framework by reading detector data “on-the-fly”. For this, I am using the accept/reject functionality of recent CRU firmwares, which allows to only output a fixed number of HB frames at the beginning of each time frame, and discard the rest. This allows a rather precise control of the data rate at the output of readout.exe, and I have adjusted the rejection rate such that the decoding of the incoming data requires about 50% of 1 CPU, while the readout.exe process itself only takes about 8%:
If I run the MCH QC on the same input stream, and using practically the same decoding routines, I see several processes taking about 100% CPU each:
Notice that the readout.exe process remains at about 8% in this case as well…
Is this expected?
Best regards, Andrea