Fixed counter sensitivity in multithreaded minibrunel test

The sensitivity was overwritten to work around threading misbehavior of the ECAL. However, it was not taken into account as the name of the concerned Algo was not matching the output, where it ends with '...' as it's too long

@mstahl This is so trivial that I would propose to put it straight in all-slots

good spot! I agree with all-slots

added all-slots label

assigned to @mstahl

added testing label

• [2020-01-14 15:42] Validation started with lhcb-test-throughput2#260
• [2020-01-14 16:03] Validation started with lhcb-test-throughput2#260
• [2020-01-14 17:10] Validation started with lhcb-test-throughput2#260
• [2020-01-15 11:32] Validation started with lhcb-test-throughput2#260

• [2020-01-15 00:09] Validation started with lhcb-lcg-dev3#1146
• [2020-01-15 00:09] Validation started with lhcb-gaudi-head#2503
• [2020-01-15 00:09] Validation started with lhcb-sanitizers#480
• [2020-01-15 00:10] Validation started with lhcb-test-throughput2#261
• [2020-01-15 00:10] Validation started with lhcb-head#2483
• [2020-01-15 00:11] Validation started with lhcb-lcg-dev4#1157
• [2020-01-15 00:12] Validation started with lhcb-gaudi-head-py3#278

Hmmm, I am not completely convinced we should hide these failures. By doing this, we will 'forget' the instability in the CALO is there, and probably not investigate it properly. Yes, I know this multi threaded failures are annoying, but isn't that kinda the point of the test, to keep poking us to try and investigate and fix this properly ?

We have basically no choice here. I agree with you on the theory, but we need green tests to validate new merge requests properly (and e.g. that they do not break in multi-thread mode) and this Ecal issue is taking far too much time to be fixed. Now we should create an issue to remember it indeed.

I agree with @sponce, the cost of keeping the failing test as a reminder is too high. I'll make an issue

approved this merge request

removed all-slots label

unassigned @mstahl

merged

mentioned in commit 99ff3ab4

The issue is Rec#118

fair enough, an issue also (mostly) addresses my concerns. As long as someone does look into it ;)

Looks like this has not completely worked. There are still some failures today (e.g. in the gcc9 dbg slot at)

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-gaudi-head/build/2504/

The change is this MR has worked. The problem is that the variations are bigger than the 10e-3 foreseen, here 1.5x10e-3 in the debug Delta Z. Shall we move up to 3x10e-3 as sensibility ?

I guess as long as we are OK with the principle of hiding these problems, we should then make the tolerances whatever they need to be.

done in !940 (merged)

mentioned in merge request Moore!349 (merged)

mentioned in issue Moore#128 (closed)

added Build label

added Calo label and removed Build label