In general rotation is ~3ms in our timeframe (10k rpm) but if you do large transfers then you read a full track and so can reading as soon as you arrive at the cylinder. Seek is sub-millisecond for less than N (~50 cylinders) in the neighborhood, and then rises as about 1MS + sqrt(distance). The 6ms seek time is computed as the average 1/3 of the surface distance. By putting cold data in 90% of the disk (use it as tape archive and backup) you can reduce seek time considerably. But.. These are minor optimizations -- the BIG optimization is to read megabytes at a time rather than kilobytes at a time.
Jim Gray Microsoft Research, Suite 1690, 455 Market, SF CA 94105, tel: 415 778 8222 fax: 425 706 7329 [EMAIL PROTECTED] http://research.Microsoft.com/~gray -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Becla Sent: Thursday, July 06, 2006 2:16 PM To: LSST Data Management Subject: Re: [LSST-data] disk seek time? Hi Jeff Yes, it is very important because the disks will see random reads (many clients competing will make it random, even if each client reads sequentially). That is why increasing data block size helps so much. I'm told here at slac that the seek time is divorced from density, and it is mostly dominated by the fact that heads have to move at all, the distance how far they have to move is not so important. So there is very little to plot, on average it is going to be around 6 msec (until the technology completely changes) Jacek Jeffrey P Kantor wrote: > Hi Jacek, > > If the seek time is that significant, perhaps we should model this as > a trend over time rather than a point. > > Jeff > > >>From: Jacek Becla <[EMAIL PROTECTED]> >>Organization: Stanford Linear Accelerator Center >>Reply-To: LSST Data Management <[email protected]> >>Date: Thu, 06 Jul 2006 13:09:36 -0700 >>To: LSST Data Management <[email protected]> >>Cc: Don Dossa <[EMAIL PROTECTED]> >>Subject: [LSST-data] disk seek time? >> >>Hello, >> >>One important knob that can significantly change database disk IO is >>disk seek time. The disk model sent by Jim Gray suggested 4 msec seek >>time and transfer rate 250 MB/sec, and that is what I was using for >>estimating disk IO so far. >>Our local (SLAC) hardware experts tell me 4 msec is optimistic, and 6 >>msec would probably be more realistic (and it is unlikely to change >>any time soon). The transfer rate on the other hand is likely to go up >>because of the density growth. Unfortunately this does not seem to >>help much for the page sizes we consider (~128-256KB). The seek time >>change dominates, e.g. if I change seek time from 4 to 6 msec and >>triple the transfer rate, required number of disks increases almost >>proportionally to seek time increase (e.g. from from 6K to 9K). >> >>So I think I will need a bit of guidance from TechAssessWG regarding >>what disk seek time I should assume for LSST for the year 2013. >> >>For convenience I'm attaching the disk model provided by Jim. >> >>thanks, >>Jacek >> >>_______________________________________________ >>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 _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
