It is known. Maybe @EwoudK wants to have a look?

I did not yet add the new correction factors to the DB12 scripts. I will have a look to add them.

I made an analysis a few months ago with the jupyter notebook I created here (I needed to tweak it a bit) https://zenodo.org/records/5647834

I got the following results:

By applying a factor of 0.83, I got the following results:

@EwoudK I can send you the raw results if you want (db12 running on many different sites with python 3.9 and python3.11).

Now, I wonder if this is the right approach as:

• we need to perform this analysis and update the code every time there is a new minor version of Python.
• it does not protect jobs from old productions to run out of time
• we saw that the raw DB12 value using Python3 was actually better than the DB12 value using Python2 on AMD processors

What is really important is to make sure that DB12 still sticks to the MC Simulation jobs: https://zenodo.org/records/7199144

To prevent jobs from old productions from running out of time, a solution could consist in constantly updating the CPUe (CPU work / event: the average CPU work of one event of a production).
In LHCb, this is computed once, before a production becomes active, by the MCSimulationTestingAgent, on a small set of computing resources from a single site.
This should probably be computed each time a job is done.

@aldbr That could be useful.
This summer, I investigated the DB12 scores compared to the LHCb workload in HEPSuite in order to calculate a correction factor for DB12.

I should check but I think the data I gathered for this were exclusively with Python 3.11. If this is the case, should I add the correction factors I computed as the ones for Python 3.11 or rather as general correction factors?