Attendees: David Abdurachmanov, Manfred Alef, Costin Grigoras, Andrew McNab

1) News: Experiment representatives, please fill the questionnaire before the next preparation meeting for the Benchmarking session of the WLCG Workshop.

2) Correlation of Benchmark Results, Job Performance, and the Number of Job Slots per Core (Update by Manfred):

• Atlas production jobs: simulation (checked with jeditaskid=10944000) as well as reconstruction jobs (11323845) are scaling well with both the estimated job performance scores (analysis by Manfred) as the static benchmarks (HS06, DB12-Numpy-at-boot). Merge jobs (11350580) are outliers with nearly no dependency on the number of configured job slots, which is not an issue because this type of jobs is i/o bound and only a small fraction of Atlas jobs.
• Alice production jobs: Costin has prepared a summary of measured Alice job performance (in units of events per hour) and also DB12-in-job values. The job performance is better than all benchmark scores except DB12-CPP in case of 2 job slots per core. Small discrepancy of measured job performance (by Alice) with estimated performance (by Manfred) of around 10% in case of 1.6 job slots per core (when normalizing results for 1.0 slots per core), but very small spread in case of 2 slots per core. There is in general very good correlation of job performance with DB12-in-job scores.
• Comparing DB12-in-job scores (from Costin) with DB12-at-boot: Matching if number of job slots is equal to the number of cores. DB12-in-job scores are always greater (by up to 47%) than DB12-at-boot if the number of slots is greater than the number of cores. Andres argues that the DB12-at-boot scores are a worst-case estimate. Nevertheless we should strictly differentiate between DB12-in-job and DB12-at-boot in further discussions.

Next meeting: in 2 or 3 weeks from now (TBD)