At 05:27 PM 10/16/96 -0500, Dave Huang <khym@bga.com> wrote:

> 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.

Hmm, that sounds more logical than my heedless assumption that it would.  I
don't use dd for drive performance measurements myself, I take a little
program that measures normal file transfers through the file system and feed
it very large files.  I find that exposes a broader variety of problems more
quickly.


> And besides, the FreeBSD driver supports wide scsi and more NCR SCSI
> chips, I think.

Those points had just occurred to me, and I was about to post an inquiry on
those when I received your reply.

The existing NetBSD driver *appears* to support wide SCSI, but I dunno cuz I
don' have no wide.  Your patch adds support for the NCR 860 chip, which I
hadn't heard of before.  (I've heard of the 810, 825 and 875.  I have the 810.)

You haven't said which Quantum Atlas you have; there seem to be 2 GB and 4
GB sizes, both in narrow and wide Fast SCSI-2 varieties.  I couldn't find
the Capella, so it's hard to compare.  Nor have you said which NCR chip you
have.

If you have a wide Atlas, you should be looking for 20 MB/sec transfers on
the SCSI bus, not 10 MB/sec, *if* you have a wide-capable NCR chip (825, 860
or 875, I believe) *and* a driver doing wide.  If you don't have a wide
Atlas, then it's hard to imagine how you could get such a drastic
difference, even if your patch enables wide where the NetBSD 1.2 driver doesn't.

The lack of specific info makes it hard to figure out what the patched
driver is doing differently that actually makes that much difference.  But
I'm no expert, and probably not the person to assess all of this anyway.
Looking for new knowledge myself, actually!


--Jim Howard
  jiho@mail.c-zone.net