On 14/04/11 18:36, Alessandra Forti wrote:
[ ... ]
> [ ... ] that figure refers to the whole simulation chain:
> generation, digitization and reconstruction
Ahh I thought it referred to the whole analsysis chain.
> The size of the event is not specified
I have been rereading GraemeS's GridPP 26 presentation and it looks like they are "typically" .0.5 to 1.5 MB (slides 13 and 14) with a bit of excursion into larger and smaller sizes, but around that order of magnitude.
> analysis requires reading a lot of eventually unused
> information to select the interesting events with
> mostly binary cuts.
There is some indirect data on events and time in slide 12 with something like 10-15/s per event. If this is on a contemporary CPU, they tend to be in the 7-15 HS06/core range, so this may imply, rounding things tremendously:
* A 1MB event can be processed in 10s on a 10 HS06 core.
* One needs 100 HS06 to process (reconstruct) 1MB/s.
Then the 5MB/s per core guideline for network and disk bandwidth seems a bit excessive, except for the cost you indicate here of scanning files to find the data to reprocess, which turns it into far more IO bound.
> [ ... ] sluggish cpus do not affect the jobs performance disk
> is more important.
I think so too, but it would be interesting to have an idea of the lower bounds. Because I suspect that some sites, especially those at the top of the chart on analysis jobs on page 43, might want to aim their purcharsing accordingly.
BTW, in GraemeS' presentation as to the overall picture I find on page 28 "Disk space at T1s is now even tighter than T2s" and on page 29 "Just not enough T2 CPUs which could eat through the work" which seems to indicate that T2 are more CPU than disk bound for ATLAS.
|