Subject: Re: Disk performance under NetBSD on A3000
To: None <amiga@NetBSD.ORG>
From: Stephen Champion <email@example.com>
Date: 04/25/1995 00:22:46
Michael L. Hitch said:
> On Apr 24, 2:50am, Stephen Champion wrote:
> > Michael L. Hitch said:
> The rotational delay is used by the file system to determine where to
> place the next 'maxcontig' segment of a file after the previous segment.
> This is [was] to give time for the kernel to process the data from one
> read and eliminate the need to wait for the disk to complete a full
> revolution to read the next consecutive block(s) from the disk. This
> was designed for the much older disk technology that did not have any
> cache or read-ahead capability, and probably slower rotational speeds.
> Almost (if not all) current SCSI disks should have an internal cache
> that does read-ahead, so as far as NetBSD is concerned, there is
> effectively no rotational delay needed. Having a non-zero value could
> even eliminate or severely reduce the read-ahead of the SCSI drive: the
> SCSI drive would receive requests for non-contiguous blocks and could
> possibly cause the current read-ahead to be flushed an a new one
> started. It depends a lot on how the read cache algorithm is designed
> in the SCSI controller.
Indeed. Before using tunefs to change the rotdel to 0, I was
seeing 500k/s reads and 425k/s writes on my Quantum LPS and 700k/s reads
and 500k/s writes on my Empire 1080S. After changing rotdel to 0, I now
have 1M/s write and 1.6M/s reads on the Empire, and the read time on the LPS
increased to 700K/s.
Interestingly, the times seem to be slightly better with a 64k
blocksize than with a 1024k blocksize.
This is the test I used:
echo "blocksize 1024k, count 10"
dd if=/dev/zero of=/dev/null bs=1024k count=16
dd if=/dev/zero of=disktest bs=1024k count=16
dd if=disktest of=/dev/null bs=1024k count=16
echo "blocksize 64k, count 256"
dd if=/dev/zero of=/dev/null bs=64k count=256
dd if=/dev/zero of=disktest bs=64k count=256
dd if=disktest of=/dev/null bs=64k count=256
The memory transfer tests both reported 4.19M/s or 3.36M/s.
I ran the tests in multiuser on an A3000/25 + Retina Z2 + A2065 on an LP105S
and EMP1080S connected to the internal SCSI controller. AFAIK, there was
no other disk access during the tests, although the results varied
slightly in some cases. DMA and syncronous transfers are enabled.
Sysinfo reports 1.2M/s on the LPS and 3.5M/s on the EMP. I
haven't done any raw tests under NetBSD (won't writing to /dev/sd1c
destroy the filesystem??).
Thank you Michael, especially for the explanation!
As I understand it, rotdel influences where on the disk data is written.
So, data written when the rotdel was 4 will not gain from the change. Is
there anything in out there (or in the standard distribution) that will
realign the data already on the drive to benefit from the change, or do I
need to back up, mkfs, and restore the file systems to affect the data
already there? I didn't see anythoing to this effect in the fsck or
tunefs man pages, or their references.
// Stephen Champion Software Eng, *ix Admin, OS Design
// firstname.lastname@example.org Hampshire College - Amherst, MA
// email@example.com Amiga 3000/25 NetBSD 1.0
#define Disclaimer "This product is completely without warranty."