OK, since we have short runs confirming the times, we probably can write the report without another long run, still....
It would be good to have a long run with the logs archived, so we can go back to them later if necessary. So, I suggest we go ahead and fix this and do one LAST long run for DC1 purposes... > From: jmyers <[EMAIL PROTECTED]> > Reply-To: LSST Data Management <[email protected]> > Date: Fri, 27 Oct 2006 13:53:15 -0700 > To: LSST Data Management <[email protected]> > Subject: Re: [LSST-data] DC1 status [DataChallenge] > > Ray and all others, > > I just double-checked with Tim and our nodelist, etc. We did run on 16 > nodes with 192 CCDs, which means 192/32 = 6 cores / CCD, which is twice > what we meant to do. This would explain why the runtimes looked longer > than I remembered. It actually means that (since we have perfect > parallelism at this level, really) we can expect 65-70 sec per image. > > -Jon > > Ray Plante wrote: >> On Fri, 27 Oct 2006, jmyers wrote: >>> As it stands, I'm a little bit confused right now - Tim says we >>> should have 3 stageslices/CPU core. With 32 hosts x 2 cores x 3 >>> slices, that should be 192 stageslices. This much looks good: >> >> Actually is 16 hosts x 2 processors, so yes 6 slices per processor. >> >> (Hmm, I guess if you were thinking 3 slices per processor, then we >> should have done even better.) >> >> cheers, >> Ray >> _______________________________________________ >> LSST-data mailing list >> [email protected] >> http://www.lsstmail.org/mailman/listinfo/lsst-data > > _______________________________________________ > LSST-data mailing list > [email protected] > http://www.lsstmail.org/mailman/listinfo/lsst-data > _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
