On Wed, 16 Oct 1996, Jim Howard wrote:
> >From a quick look at the patch included in the PR, I gather that the main
> improvement is to replace a maximum number of command queue tags
> (SCSI_NCR_MAX_TAGS) with a default number of tags (SCSI_NCR_DFLT_TAGS), so
> presumably the number of tags can be increased, and this is what allows the
> drive to work at full speed where it couldn't before.
> 
> If so, you might attain the same objective simply by increasing the maximum
> number of tags (SCSI_NCR_MAX_TAGS) in the existing NetBSD driver to an
> appropriate figure.

I really have no idea what the changes to the driver actually do, but
there were other things besides the change from MAX_TAGS to DFLT_TAGS that
looked like they might make a difference. And with the driver from 1.2, I
had to turn off tags completely to avoid assertion failures. After seeing
how FreeBSD's driver performed so much better, I tried recompiling my
kernel with the NetBSD 1.2 driver, but with tags turned back on, and I
didn't see any improvement at all. So, I suspect that it's not the tags...

Also, from what I understand, tagged command queuing lets you send a bunch
of requests to the drive, and the drive responds to them in whatever order
would be fastest, right? It doesn't seem like that'd affect a sequential
read from the drive very much.

And besides, the FreeBSD driver supports wide scsi and more NCR SCSI
chips, I think.
-- 
Name: Dave Huang     |   Mammal, mammal / their names are called /
INet: khym@bga.com   |   they raise a paw / the bat, the cat /
FurryMUCK: Dahan     |   dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 20 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++