Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Veracity of current CPU time values #2

Open
kenbloom opened this issue May 26, 2017 · 6 comments
Open

Veracity of current CPU time values #2

kenbloom opened this issue May 26, 2017 · 6 comments
Assignees

Comments

@kenbloom
Copy link
Owner

I got the numbers for the current-day GEN/SIM/DIGI/RECO out of the spreadsheet that was used for our most recent C-RSG request:

https://cms-docdb.cern.ch/cgi-bin/DocDB/ShowDocument?docid=13271

I used PU=35 and assumed that was a suitable luminosity scenario through both Run 2 and Run 3, given that the instantaneous luminosity isn't supposed to change much from here through Run 3. But I might have totally misinterpreted the numbers, so can someone please check? Maybe I will try assigning the issues to Chris and Liz. I've never assigned an issue before.

Also: there wasn't a separate value for DIGI in the spreadsheet. But since re-DR = 350 HS06 and RECO alone is listed as 250 HS06, I assumed DIGI = 100 HS06.

@kenbloom kenbloom assigned kenbloom and Dr15Jones and unassigned kenbloom May 26, 2017
@Dr15Jones
Copy link
Collaborator

@davidlange6 @slava77 I was hoping either of you might be able to provide meaningful comments on the numbers provided about processing requirements.

@slava77
Copy link

slava77 commented May 26, 2017

It's a question to Tom (I think he entered the numbers based on my inputs).
@tommasoboccali

@tommasoboccali
Copy link

tommasoboccali commented May 26, 2017 via email

@tommasoboccali
Copy link

ok, now I see it - btw interesting, can we discuss at some point what is this python ;)

We used these numbers from

  • RECO only: ttbar reco from Slava. Assuming (which we believe is ~ true) his machine has 10 HS06 per core, we ended up in 20 sec per ev + some 10% (going to 25 sec/ev = 250 HS06s/ev)
  • DR: the D part (which gives a +10 sec) can even be too low ... I think I saw a table by Slava at some point

AH, ok: here https://indico.cern.ch/event/624140/contributions/2533493/attachments/1438070/2212438/reco_2017_OnC_040317.pdf

it says D is 16, so more than 10.
The numbers in the presentation (page 10), would give on

  • reco (which hs to include miniaod time) = 18.5 sec (I think for real reco the +10% missing is about alca but not sure i remember)
  • D+R = 34.5 sec

so in this last release (4 months after the estimates which entered the doc), reco is probably a bit too high, DR seems ~ ok

tom

@kenbloom
Copy link
Owner Author

Hey, it's becoming a party around here! What is this python? I keep telling people it's an expression of my midlife crisis (but I'm kidding).

So the bit of code (currently in cpu.py, but we'll get it into a JSON file I'm sure) that currently is

data_reco_time_lhc = 250 #this is per HS
mc_gensim_time_lhc = 500 #this is per HS
mc_digi_time_lhc = 100 #this is per HS

should really be more like

data_reco_time_lhc = 185 #this is per HS
mc_gensim_time_lhc = 500 #this is per HS
mc_digi_time_lhc = 160 #this is per HS

My main concern is that I have got the current reconstruction and the HL-LHC expectations in the same units...there is that factor of 10 for Slava's computer that I keep worrying that I'm not counting or double counting or whatever.

@slava77
Copy link

slava77 commented May 26, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants