Date: Wed, 1 May 1996 05:26:44 +1000 From: Bruce Evans <bde@zeta.org.au> To: koshy@india.hp.com, msmith@atrad.adelaide.edu.au Cc: current@freebsd.org, hackers@freebsd.org Subject: Re: lmbench IDE anomaly Message-ID: <199604301926.FAA19369@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >> two simultaneous runs on the scsi disk >... >> The performance degradation per process is around 2x which is to be expected. >> The overall throughput is around the same as the single benchmark case. >> >> However when the same exercise is repeated with the IDE disk: >... >> Here we see a 8x degradation per process; 4x in terms of total throughput. Using dd instead of lmdd, I get a 26x degradation per process for both SCSI and IDE (SCSI: P133, ncr'810, Quantum Grand Prix; speed reduced from 2048K/s to 78K/s; IDE: 486/33, slow Samsung drive; speed reduced from 682K/s to 26K/s) >That's about right. The SCSI disk gets the chance to sort the I/O to suit >itself, optimising its performance. The IDE disk only gets to look at one >transaction at a time, so it's at the mercy of the disksorting code in >the operating system. I don't know that FreeBSD's disksort stuff is >terribly wonderful, but I'd happily stand corrected. disksort() is a no-op for this test because the queue length is always 1. Neither disk gets much chance to sort the i/o. The speed depends on the caching strategy and size of the cache. The i/o pattern apparently completely defeats read-ahead and/or track buffering for both my drives. On another of my drives (SCSI, 486DX2/66, slow Toshiba drive) the degradation was only 2x (from 208K/sec to 104K/sec). This doesn't mean much since the drive is so slow for the small 1k block size to begin with (it needs a block size of 16K to approach the platter speed). OTOH, a larger block size would be more likely to defeat the drive's caching. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604301926.FAA19369>