Subject: siop(4) and tagged queuing
To: None <current-users@netbsd.org>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: current-users
Date: 10/23/2000 18:46:28
Hi,
I just added tagged queuing support to siop(4), and also reworked a bit the
driver so that it should create less interrupt and PCI load.
It should also support the QUEUE FULL status (which ncr(4) failed to handle),
but I didn't find a drive which would generate such a condition. If someone
has the hardware to test please tell me how it goes.
I did some bonnie runs on a 4G UW IBM drive attached to a 875 (machine is a
PII/200):
-current, with 1.5 siop code:
-------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
50 11302 92.6 11782 28.1 2960 10.2 8136 86.0 12420 20.4 129.0 2.8
50 11228 93.9 12032 30.9 2896 10.1 8454 89.0 12346 20.3 130.8 3.0
50 11232 91.5 12042 29.7 2906 10.1 8262 87.5 12542 20.3 131.6 3.0
-current with new siop code, tagged queueing disabled:
50 11286 95.1 11752 28.5 2972 10.4 8300 86.9 12452 19.3 129.7 2.7
50 11403 95.8 11964 29.4 2900 10.2 8240 86.8 12496 20.1 134.1 2.8
50 11385 95.7 11502 29.0 2934 10.4 8234 86.7 12496 20.2 131.0 2.7
-current with new siop code, tagged queueing enabled:
50 8873 77.2 8908 21.2 2951 9.9 8030 84.6 12420 19.7 129.2 2.6
50 8742 75.5 8845 20.7 2889 9.6 8184 86.3 12441 19.9 129.5 2.7
50 8791 77.5 8781 21.5 2920 9.6 8175 85.9 12445 19.4 129.2 2.7
So on average the new code is sighly faster (it should be more obvious
on a adapter without a internal RAM). However tagged queuing seems to not be
that good, especially for write - maybe it hurts with the disks' cache.
I'd be interested in results with others disks :)
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
--