[2513] in linux-scsi channel archive
Re: Adaptec 2940 support
daemon@ATHENA.MIT.EDU (Zlatko Calusic)
Mon Sep 22 14:17:33 1997
To: Jeff Noxon <jeff@planetfall.com>
Cc: "David Sparc Miller" <davem@jenolan.rutgers.edu>,
linux-scsi@vger.rutgers.edu
Reply-To: Zlatko.Calusic@CARNet.hr
From: Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
Date: 22 Sep 1997 19:47:29 +0200
In-Reply-To: Jeff Noxon's message of Mon, 22 Sep 1997 12:13:21 -0500
Jeff Noxon <jeff@planetfall.com> writes:
> Don't enable the /proc stuff, don't enable any extra features you don't
> have to (tagged queuing is probably ok though), and you should be fine.
> You can get away with more if you install some of the latest patches. I
> am running 2.0.31-pre9 without any patches, and it is stable.
I'm using only "bleeding edge" kernels at the moment, 'cause they've
proved as very stable and reliable. This is excerpt from my
/usr/src/linux/.config:
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_TAGGED_QUEUEING=y
CONFIG_OVERRIDE_CMDS=m
CONFIG_AIC7XXX_CMDS_PER_LUN=8
CONFIG_AIC7XXX_PAGE_ENABLE=y
# CONFIG_AIC7XXX_PROC_STATS is not set
CONFIG_AIC7XXX_RESET_DELAY=5
I decided to lower the reset delay to 5 seconds (from the default 15)
because my kernel completely locks while SCSI devices are being
reseted, and I don't like that behaviour. Now my Linux is back sooner,
atleast. :)
> Have you tried IRQ unmasking? Enabling caches and 32-bit DMA?
>
Well, of course. :)
I'm using "hdparm -u1 -m16 -a16 -A1 -c1 /dev/hda" in the boot
sequence. I come to that line after many days of experimenting.
I even tried generic-dma patch that was posted on linux-kernel list
awhile ago, and it worked (after some changes) on my SiS 5513 chipset,
but I wasn't satisfied with the performance. The patch somewhat
improved reading speed (including CPU utilization), but writing speed
went down (and writing used even more CPU than before!?!).
> This is the bonnie result with my raid0 array on twin wide SCSI channels:
>
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 100 4297 95.3 7597 62.9 3045 48.9 4188 85.3 11228 71.4 102.6 7.4
>
Hm, I can't say that those %CPU columns are low.
Compared to results I got on Sun, these are definitely too high.
Sun Ultra 1 (UltraSparc 143MHz, 64MB RAM, 2.1GB SCSI disk) running
Solaris 2.5.1:
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 5080 78.4 5017 14.5 1615 9.1 5055 95.3 5149 11.1 86.3 2.7
And this is the same machine running UltraLinux v2.1.44 (thanks to Dave
Miller) :)
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
200 3117 45.0 3219 11.5 1494 8.7 3331 61.7 3579 7.7 39.9 1.1
Note that %CPU, while doing block I/O, is less than 15%, no matter if
reading or writing, no matter what OS you use!
We can also see that DaveM has some work to do on improving read/write
speed. :)
Regards,
--
Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
P.S. Dave, since you're mentioned in this mail, you get a courtesy
copy. You can flame me at will. :)
