Test for max candidates exceeds time limit

Looks like there is now a problem with Moore_max_candidates_test PR test (!436 (merged)): the new nightly system has recently introduced (back) a hard time limit of 12h on running jobs (the story behind is that a Moore PR job, due to changes in an MR it was testing, ended up in a dead-lock and was blocking the queue for all other throughput tests for nine days (and nobody raised any questions), until it was finally spotted and aborted).

It seems this particular test is taking a bit longer than 12h, so it is getting killed by the system. Is it possible to change it to fit the limit (e.g. slightly reduce the maximum number of events it runs over)?

/cc @rjhunter @nskidmor @eleckste

assigned to @dmagdali

The test should be doing something similar to the bandwidth tests, over a similar number of events (I think), so should take around the same amount of time.

Are you multi-threading Moore @dmagdali? We get 16 threads on the LHCbPR machine, so this will make a big difference. Could you also check that the input file is being downloaded to the local disk before running - again not reading over the network will save a lot of time.

From experience of the bandwidth tests on this machine, with the above points addressed, and running the whole of HLT2, I'd suspect a few 100k events can be done in O(1-few) hours. We'd need good justification I guess for this test to take more than 2 hours, because it will block up the system otherwise.

mentioned in merge request lhcb/Moore!4402 (merged)

mentioned in merge request !522 (merged)

closed