Date: Tue, 27 Feb 1996 21:01:06 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Dave Andersen <angio@aros.net> Cc: questions@freebsd.org Subject: Re: Ncr scsi: overlapped commands attempted Message-ID: <199602272001.AA11333@Sysiphos> In-Reply-To: Dave Andersen <angio@aros.net> "Re: Ncr scsi: overlapped commands attempted" (Feb 27, 12:45)
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 27, 12:45, Dave Andersen wrote:
} Subject: Re: Ncr scsi: overlapped commands attempted
} Lo and behold, Stefan Esser once said:
} > On Feb 23, 19:10, Dave Andersen wrote:
} > }
} > } ABORTED COMMAND asc:4e,0 Overlapped commands attempted
}
} > } P133 - 32 MB, 2 1gb NEC SCSI drives, 1 2gb HP SCSI drive
} >
} > Yes: Switch off tagged commands ... :(
} >
} > options "SCSI_NCR_DFLT_TAGS=0"
} > options "SCSI_NCR_MAX_TAGS=0"
}
} Works like a charm with these options set.
Well, why am I not at all surprised ... :)
} > You can selectively enable tagged commands
} > for the other drives from /etc/rc.local:
} >
} > ncrcontrol -t0 -t1 -s tags=4
}
} I get an error message when I try this:
}
} ncrcontrol: incompatable with kernel. Rebuild!
}
} Is this something that only works with -current, or am I missing some
} -stable changes to ncrcontrol? (I'm using -stable at the moment)
The sources can be found under
/usr/src/usr.sbin/ncrcontrol
Just go into that directory and (as root) type
make clean all install
to rebuild and install a version compatible to
your kernel. Since "ncrcontrol" accesses kernel
data structures, it must be compiled with matching
definitions, and it seems the kernel definitions
changed at some time and "ncrcontrol" predates
those changes ...
} What kind of performance hit am I looking at if I leave tagged commands
} off? The other option is to swap the drive for something else, which I'm
} not at all above doing if it's going to be a headache.
I've made a few tests a few days ago:
-------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
tags=0 100 1894 98.7 6052 52.3 2412 45.8 1863 98.5 6302 66.6 81.2 7.9
tags=2 100 1689 98.5 6108 55.9 2696 54.3 1865 98.6 6285 65.5 80.4 7.8
tags=4 100 1693 98.9 6067 54.1 2768 52.2 1512 98.6 6448 71.2 81.1 8.0
tags=8 100 1867 98.2 6066 52.5 2793 52.4 1858 98.7 6468 71.8 79.7 7.9
tags=16 100 1687 98.8 5914 50.9 2852 54.2 1507 98.8 6462 71.1 80.4 8.1
tags=16 100 1887 98.6 5913 53.4 2813 54.4 1861 98.7 6474 71.9 80.2 7.9
tags=4-ot 100 1670 98.5 3350 26.9 2255 40.0 1508 98.6 5965 65.4 79.6 7.8
tags=4-ot 100 1695 98.7 3325 29.3 2242 41.4 1864 98.7 5791 62.4 80.3 7.8
The tags=0 line corresponds to "NO tags", and
all but the two last lines give results for that
number of simultanous commands issued with a
"simple" tag. The last two lines show what can
be had with 4 "ordered" tags (i.e. the drive
must complete the commands in the order sent).
The "per char" results erraticly jump between
two specific values. This appears to be an
artefact of my current CPU/cache combination
(AMD 5x86 with WT primary and secondary cache).
As you can see, the "rewrite" values show most
advantage if tags are used. I had chosen 4 tags
as the default, one year ago, and it still appears
to give the best results for the effort :)
} > If this works for you, then I can provide
} > you with another patch, which might allow
} > enabling tags on the HP drive, too.
}
} I'll guinea pig happily if I can patch it off of -stable.
Well, I'll send a very short patch in separate
mail, and you may want to test it ...
Regards, STefan
--
Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021
Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160
==============================================================================
http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602272001.AA11333>