Nightly test of SL7, 32-bit, optimized is ~2 CPU-seconds per event. First event is ~70-80 CPU-seconds, which becomes negligible at O(1%) for files with a few thousand events.

Total events=~3.3B and total files=~50k:

> get_file_list.pl -keys 'sum(events)' -cond year=2024,trgsetupname=pp200_production_LowLuminosity,filetype=online_daq,storage=hpss,sname2=st_physics
3338594169
> get_file_list.pl -keys 'sum(events)' -cond year=2024,trgsetupname=pp200_production_LowLuminosity,filetype=online_daq,storage=hpss,sname2=st_physics_adc
15632831
> get_file_list.pl -keys 'count(fdid)' -cond year=2024,trgsetupname=pp200_production_LowLuminosity,filetype=online_daq,storage=hpss,sname2=st_physics
49831

(Ignoring the ADC files, which are essentially negligible...)

So files have on average ~67k events in them, but many files have something like 110k events in them!

Thus, for 32-bit optimized, we need about ~7e9 CPU-seconds = ~80k CPU-days. That's ~80 days if given 1k CPUs.

I tried a 32-bit vs. 64-bit comparison by running the nightly test job interactively at the same time on a single node, and got a ratio of 1.3:1 for duration. That's close enough to use 4:3 as the ratio, which leads to...

64-bit optimized would be about ~60 days (~2 months) given 1k CPUs.

The other question is how long the longest jobs might take. At 2 CPU-seconds per event, a file with 1.1e5 events = 2.2e5 CPU-seconds = ~2.5 CPU-days, and 64-bit optimized should be on the order of ~2 CPU-days for the longest jobs even if they're a little slower. Both of these are just fine.

-Gene