On Wed, Jan 24, 2007 at 09:11:18PM -0500, Umnada Tyrolla wrote: > > When compiling code, most transfers will be small. A single hard drive > > spinning at 7200rpm is in theory capable of 240 transfers per second > > (assuming each transaction requires the platter to rotate on > > average by half > > a turn), > > That doesn't seem like correct analysis.
It was a very dirty first approximation. The simple model is that a random read or write requires the drive to: 1. seek to the correct track 2. wait for the correct sector to come around 3. perform the transfer I was assuming that (1) and (3) are zero, and (2) averages at half a revolution. Given high data densities and small transfers, (3) is going to take a tiny fraction of a revolution so that's probably reasonable. Assuming a zero seek time is definitely much less realistic. Looking at e.g. http://westerndigital.com/en/products/Products.asp?DriveID=249 This shows a "read seek time" of 8.7ms, although a "track-to-track seek time" of 0.6ms. So if you're doing elevator seeking on a localised part of the disk it may be low. The quoted "average latency" of 4.2ms is half a revolution at 7200rpm. Now, if you take 8.7ms + 4.2ms, then you only get 77 tps. The trouble with this analysis is, actual rates I see on even cheap hard drives are higher in practice. Here's an old desktop 40GB IDE drive in an OpenBSD 4.0 firewall: cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz ("GenuineIntel" 686-class) 2.81 GHz ... wd0 at pciide0 channel 0 drive 0: <ST340015A> wd0: 16-sector PIO, LBA, 38166MB, 78165360 sectors According to the specs at http://www.seagate.com/support/disc/ata/st340015a.html this is a 5800rpm drive. But when I run bonnie++, the "random seeks" test reports 105.5 tps, which also agrees with what "iostat 2" shows during that test: 0 37 16.00 105 1.64 0.00 0 0.00 0.00 0 0.00 0 0 1 0 99 0 37 16.00 102 1.60 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 37 16.00 101 1.58 0.00 0 0.00 0.00 0 0.00 0 0 1 0 99 0 37 16.00 107 1.67 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 tty wd0 cd0 fd0 cpu tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id 0 37 16.00 102 1.60 0.00 0 0.00 0.00 0 0.00 0 0 0 0 99 0 110 16.00 107 1.67 0.00 0 0.00 0.00 0 0.00 0 0 1 0 99 0 37 16.00 104 1.63 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 ... etc I guess this just means my head isn't screwed on right, or that bonnie++ isn't seeking across wide parts of the disk. Interestingly, during other tests I see between 200 tps (rewrites) and 500 tps (block writes and reads). Perhaps the drive is doing some fairly aggressive read-ahead and write-behind caching. I'm pretty sure that values in the 200-300 tps range are what I've observed in the past when throwing some load on a small mailserver, e.g. using postal and rabid. http://www.coker.com.au/postal/ > I think you're a phenomenologist. Me too, though. I saw this store > worker unloading a shopping cart starting with the boxes on top, so I'm > pretty sure workers put lowest priority boxes on the bottom of the cart. Clearly it's impractical to unload starting from the middle or the bottom of the cart. I'm afraid I don't understand the point though... Regards, Brian.
