loose cut on lifetime bds2ppbarppbar

loose cut on lifetime bds2ppbarppbar (1ps -> 0.2ps).

Rates (100k minbias 2024):

Line:	 Hlt2BnoC_BdsToPpPmDecision    	 Incl: 0.0114 +/- 0.0113 kHz,	Excl: 0.0114 +/- 0.0113 kHz
Line:	 Hlt2BnoC_BdsToPpPmPpPmDecision	 Incl: 0.0456 +/- 0.0227 kHz,	Excl: 0.0456 +/- 0.0227 kHz

added 2024data-selections BnoC hlt2 labels

requested review from @zewen

requested review from @msaur

changed the description

This MR looks nice to me. I'll run 100 event rate test to see if there is any problem.

resolved all threads

approved this merge request

mentioned in commit 5bc0c7db

merged

mentioned in merge request !3052 (merged)

@jbaptist @zewen But do we have at least basic bandwidth numbers to see that event size is fine as well?

Hi @msaur , I run the bandwidth test by 10k events, before this MR merged into bnoc_run3, the total bandwidth is 1140(kHz)*1.8069(MB)/10000=0.2060 (GB/s), after this MR merged, the total bandwidth is 1140(kHz)*1.8094(MB)/10000=0.2063 (GB/s),

do we need to only run BdsToPpPm and BdsToPpPmPpPm lines to see the bandwidth due to these two lines?

We should check bandwidth for every new MR. In some cases where cuts are only tightened then it is not a big issue, but change of cuts in this case went both ways - something was loosedned and something tightened.

Additionally, 10k is a low statistics and your numbers are rather lower compared to official bandwidth values. What sample are you using?

I use this script, link. It uses expected_2024_min_bias_hlt1_filtered sample. I change the from Hlt2Conf.lines.topological_b import all_lines to from Hlt2Conf.lines.bnoc import all_lines, and also change the options.evt_max = 5000 to options.evt_max = 10000

I can try to run 100k events to see if the total bandwidth is the same as the official bandwidth result.

So it will be probably due to sample size, as in the today's official test BnoC is around 0.4 GB/s

I can try to run 100k events to see if the total bandwidth is the same as the official bandwidth result. -> Probably no need to rerun it now, as we will have to run official test when running ci-test for our MR anyway, point is that bandwidth should be provided by proponents.

Oh, I see. I'll ask the proponents to also provide the bandwidth test results for lines loosing selections before merging it. Thanks @msaur .

And I guess the bandwidth increasing due to this MR is acceptable, which is about 0.3MB/s with 10k events test.

Ah, sorry, I found 0.2063 (GB/s) is the result before merging this MR, while 0.2060 (GB/s) is after merging.

So the bandwidth decreased due to this MR.

Those are good news.

Nice! Thank you both.

resolved all threads