Hello all, I updated document-2116 in docushare with this new version. Please consider this version baselined (except the Planning sheet). Thanks!
Jeff > From: Chris Smith <[EMAIL PROTECTED]> > Date: Sun, 30 Jul 2006 20:37:29 -0400 > To: Chris Smith <[EMAIL PROTECTED]> > Cc: Jeffrey Kantor <[EMAIL PROTECTED]>, Tim Axelrod <[EMAIL PROTECTED]>, LSST > Data Management <[email protected]> > Subject: Re: [LSST-data] Re: CPU estimates for query load [TechAssessWG] > > > Hi all, > > I've updated the CPU spreadsheet once again based on input (and typo > corrections) from Jeff. > > Major changes/additions include: > > - CPU summary includes Ray's estimates of CPU needs for "operational" > infrastructure such as file servers, web portals, etc.. Note that > the current model has this as a CONSTANT with time, which is probably > not right (at least for file servers?). This info is summarized in > the "operations" sheet. > > - I've added a planning sheet, which matches the NEEDS (from the CPU > summary sheet) against 3 possible "CPU refresh" scenarios: one in > which we refresh at the end of yrs 3, 6, and 9 (NOTE: so new CPUs are > available in yrs 4, 7, and 10); one in which we refresh at yrs 4 and > 8; and one in which we refresh in year 5. > > - On-demand need for reduced images is summarized in the ReducedImgs > sheet. As pointed out, this ASSUMES THAT ALL CALIBRATION PRODUCTS > ARE ARCHIVED, so that reduction of any science image only requires > retrieval and application of calibration images, NOT re-creation of > calibration images. > > - the Transient on-demand need has been modeled based on (a) the same > numbers and percentages used by Jacek for storage & queries (from DM > Overview ppt), with further somewhat arbitrary fractions of > "interesting alerts". > > Here I ASSUMED THAT THERE WAS A 30 NIGHT CACHE of reduced images > kept, allowing immediate photometry at the sites of new alerts of the > previous 7 to 10 epochs. This will (a) allow us to populate the > catalog with pre-discovery photometry of almost all alerts, and (b) > allow us to provide both that photometry and the reduced images to > those interested in the alerts. > > I wasn't sure of the number of visits per year per field, but I > assumed roughly 10 times per month times 5 months per year, or 50 > visits. > > I made what I think is a DUBIOUS ASSUMPTION that we can re-reduce > data on a CCD scale, as opposed to an IMAGE scale. This may be true, > but to help be sure I've added a factor of 2 "overhead" in the > scaling from TFlops/image > (so TFlops/image / 200 CCDs * 2 overhead). This should cover, for > example, fetching all neighbooring CCDs which contribute crosstalk, > so that the images can be crosstalk corrected, and any other > additional overheads AND/OR overheads which don't scale with image size. > > I've attached the Excel file, and ALSO uploaded it to the Docushare > so that Don and others with attachment-phobic email servers can see > it. It is known on the docushare as as Document-2116. > > The floor is now open for discussion! > > Cheers, > Chris > > ======================================================================== > = > Dr. R. Chris Smith EMAIL: [EMAIL PROTECTED] > National Optical Astronomy Observatory > Cerro Tololo Inter-American Observatory > 950 N. Cherry Ave. Casilla 603 > Tucson, AZ 85719 La Serena, CHILE > Office: 520-318-8555 FAX: 520-318-8170 > WWW: http://www.ctio.noao.edu/~chris > ======================================================================== > = > > > > _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
