-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, November 25, 2001, at 07:35 , Lev Selector wrote:
> Below I describe a perl script I used to measure disk performance. I don't think that's what you actually measured. Of course, it depends on your definition of "disk performance." > For fun I decided to investigate (using Perl) how much upgrading > to SCSI will boost the performance. I'll make a blanket prediction right now and suggest, for this test script, "not much, if at all." > Searching Google and CPAN didn't give me any Perl scripts > or modules to measure hard drive performance. That's because "hard drive performance" is a very broad description. > (Benchmark module is not useful for this purpose). > So I wrote a primitive (and not accurate) script (see below). > I tested it on my home Windows PC and on Linux Web Server. > Both are running Pentium III 500 MHz, 100MHz bus, 8GB IDE hard drives. > Results of the test below demonstrate that on > Linux disk operations are ~ 3 times faster. ?? What your script measured was large file sequential write performance, and probably not very well at that. Linux uses unallocated memory for disk buffer space and "lazy writes" to the physical disk. In other words, when you ask the kernel to write a chunk of data to disk, it copies it to a disk buffer and returns success. The data isn't actually written to the disk until the buffer is needed for something else; I think a low-priority thread also writes back dirty buffers periodically. I wouldn't be surprised if Linux and/or the ext2 filesystem that Linux normally uses is smart enough to write back multiple dirty buffers if they represent contiguous portions of the same file -- which means minimal head movement during the write. So, what I suspect is happening on the Linux box is something like this. For the first part of a run of your script, "writes" go only to disk buffers. On the next write after the available buffers are exhausted, one or more are written to physical disk as one big chunk, with little or no head movement in the drive. The rest of a run of your script repeats the cycle -- furious writing to disk buffers, followed by a pause as data is streamed to the disk. Most likely, one or more dirty buffers are not written to disk until after your script exits, which means a large error is introduced into the accuracy of its timing. I don't know how Windows handles disk writes, but I'd guess (and it's a very hazy guess) that it doesn't buffer writes like Linux does, based on the timings you reported. To top things off, large file sequential writes are not the bulk of disk accesses for most of us. Small (the size of your hardware's paging blocks; 4K for most micros, I think, and 16K for Alphas?) random reads more accurately simulate the disk accesses required for starting programs or serving web pages, for instance. - -- Craig S. Cottingham [EMAIL PROTECTED] PGP key available from: <http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0xA2FFBE41> ID=0xA2FFBE41, fingerprint=6AA8 2E28 2404 8A95 B8FC 7EFC 136F 0CEF A2FF BE41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (Darwin) Comment: For info see http://www.gnupg.org iD8DBQE8AbGdE28M76L/vkERAu/vAKDfZGUAWa+nf21etspL1quFsfhaOQCgk22W vNh+DQd8do4HdCU5PZUgyj8= =Km3R -----END PGP SIGNATURE-----
