QC CPU usage

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

There is a --rate option you can use to tweak that. A proper fix is in the pipeline.

Thanks! This does not seem to be a limiting factor (yet) in our simple set-up. I just wanted to report the observation in case it was something new.

Thanks for the report. The tricky part is that different components have a different sweet spot and for some of them have an as high rate as possible is the correct thing to do. Anyways, as I said at some point this will be properly solved.