Hi,
First of all: Thanks a lot to everyone for your replies.
It turned out that I've stumbled accross a property of the UBC (unified
buffer cache) which is used by AdvFS and which causes these results.
The SCSI I/O speed is just fine, both on the old, build-in controller
as well as with the second new controller. I've checked this with:
time dd if=/dev/rrz8c of=/dev/null ibs=1024k count=100
which takes about 15 seconds and thus yields about 100/15=6.6MB/s which
is about what I would expect for my ST32550N, 7200rpm disks.
In order to get correct results, I need to run "bonnie" twice and take
only the second results. Here is the explanation for that from:
"Alan Rollow - Dr. File System's Home for Wayward Inodes."
alan_at_nabeth.cxo.dec.com:
Digital UNIX uses a unified buffer cache, where the memory
used by the file system cache is the same memory that
processes use for data. It has the advantage of making
more memory available for caching, in I/O intensive loads.
The disadvantage is that when a large file is written it
will try use all of free memory to cache it and will page
out whatever happens to be idle to get more memory for the
cache. When the out-going memory is paged or swapped
depends on how the pager decides to move it; one big swap
is sometimes quicker than going a few pages at a time.
The first time you run Bonnie for a particular file system
it will page lots of things out. If you run it again right
after that you'll see the I/O load without most of the extra
paging load.
If your I/O load is going to tend to be sequential I/O on
large files, you may want to limit the amount of memory
that the cache will use. One of the sysconfig parameters
controls this. It probably has the components "ubc", "max"
and "percent" in the name. The performance tuning guide
may have other suggestions on how to tune for heavy sequential
I/O loads.
Thanks very much Alan.
Thanks as well to Dave Golden <golden_at_falcon.invincible.com> who
suggested to check the pk* variables in console mode with "show pk*".
The variables "pka0_fast" and "pkb0_fast" were already set to 1, though.
Thanks to Dave Cherkus <cherkus_at_UniMaster.COM> who told me the following:
> Folklore has it that the ncr810 controllers are very inefficient. They
> have a smart scsi chip, but the chip needs a microprogram, and to get
> that program it has to read it from main memory (the reason the board
> is $50 is it doesn't have a ROM to hold the microprogram), and the pci
> bus cycles needed to read that microprogram kill throughput. I've
> never confirmed this myself, but if one had a pci bus analyzer it
> should be relatively straightforward to do...
Yes but boot messages say:
Loading SIOP: script 800600, reg_81810100, data 405c8568
scsi0 at psiop0 slot 0
rz3 at scsi0 target 3 lun 0 (LID=0) _(SEAGATE ST32550N 0014)
psiop1 at pci0 slot 6
Loading SIOP: script 80c600, reg_81810000, data 405c8968
scsi1 at psiop1 slot 0
rz8 at scsi1 target 0 lun 0 (LID=1) _(CONNER CFP4207S 4.28GB 2B4B)
rz9 at scsi1 target 1 lun 0 (LID=2) _(SEAGATE ST32550N 0021)
The "Loading SIOP: script ..." implies that the microprogram is loaded
only once! I tend not to believe this roumor as it would be a really brain
damaged design not to have the microprogram storage on-chip of the
SCSI controller.
Numerous people were interested in the Bonnie benchmark itself. It can
be copied from my ftp server:
ftp://finwds01.tu-graz.ac.at/pub/unix_utils/Bonnie.tar.Z
And finally this is my original posting:
On Wed, 18 Dec 1996, Thomas Leitner wrote:
> As suggested in this list, I bought one of these $50 NCR PCI SCSI
> controllers and plugged it into my ALPHAPC64 board running Digital
> Unix 4.0A. Everything went fine. The controller is seen in the
> console and so are the devices attached to the controller. After
> rebuilding the kernel with "doconfig" which just added the lines:
>
> bus psiop1 at pci0 slot 6 vector psiopintr
> controller scsi1 at psiop1 slot 0
>
> to the config file and changing /etc/fdmns/inw_dmn to contain links
> to the new devices /dev/rz8c and /dev/rz9c everything is up and
> running as it was before.
>
> Now out of couriosity, I've ran the BONNIE disk i/o benchmark to
> see if anything has changed in the I/O speed and I found the following
> dramatic differences:
>
> before adding new controller
>
> -------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 3700 73.9 6321 27.5 1588 7.5 4947 87.5 7850 22.9 135.1 4.8
>
>
> after adding adding 2nd SCSI controller
>
> -------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 2187 45.9 2514 12.9 982 4.8 2192 39.3 2510 8.0 109.6 3.5
>
> and this is on both, the old SCSI controller with only the system disk
> attached, as well as on the new, 2nd SCSI controller with the users home
> disks attached.
>
> Needless to say that this is not quite satisfactory.
>
> Questions:
>
> 1.) I left the default INTA# interrupt configuration on the new
> controller? Should I change to INTB# ? Would this help?
>
> 2.) In console mode, I've entered "isacfg -init" and "init". Is it
> possible that this re-sets some SCSI variables to the default?
>
> 3.) Is it possible that both controllers somehow now are defaulting to
> non FAST SCSI or something? (I remember the FAST_SCSI_A and
> FAST_SCSI_B settings on the old DEC 3000/600) ?
>
> 4.) Any other ideas anyone?
Tom
--------------------------------------------------------------------------
T o m L e i t n e r Dept. of Communications
Graz University of Technology,
e-mail : tom_at_finwds01.tu-graz.ac.at Inffeldgasse 12
Phone : +43-316-873-7455 A-8010 Graz / Austria / Europe
Fax : +43-316-463-697
Home page :
http://wiis.tu-graz.ac.at/people/tom.html
PGP public key on :
ftp://wiis.tu-graz.ac.at/pgp-keys/tom.asc or send
mail with subject "get Thomas Leitner" to pgp-public-keys_at_keys.pgp.net
--------------------------------------------------------------------------
Received on Thu Dec 19 1996 - 11:11:29 NZDT