From owner-freebsd-current Mon Oct 21 11:56:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA03796 for current-outgoing; Mon, 21 Oct 1996 11:56:55 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA03787 for ; Mon, 21 Oct 1996 11:56:35 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-49.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA29743 (5.67b/IDA-1.5 for ); Mon, 21 Oct 1996 20:52:27 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.6/8.6.9) id UAA03387; Mon, 21 Oct 1996 20:51:41 +0200 (MET DST) Message-Id: <199610211851.UAA03387@x14.mi.uni-koeln.de> Date: Mon, 21 Oct 1996 20:51:41 +0200 From: se@zpr.uni-koeln.de (Stefan Esser) To: jgreco@brasil.moneng.mei.com (Joe Greco) Cc: michaelv@MindBender.serv.net (Michael L. VanLoon -- HeadCandy.com), scrappy@ki.net, michaelh@cet.co.jp, mrcpu@cdsnet.net, current@freebsd.org Subject: Re: Iozone: local vs nfs drives In-Reply-To: <199610181428.JAA02841@brasil.moneng.mei.com>; from Joe Greco on Oct 18, 1996 09:28:28 -0500 References: <199610181428.JAA02841@brasil.moneng.mei.com> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Joe Greco writes: > > Ah yes. It must have been someone else that posted that he was using > > an Adaptec 2940. I mis-threaded... > > > > I know the NCR supports tagged-command-queuing, also, but since I > > don't use one (except on some NT machines at work), I don't know what > > you do to enable it. Joe Greco would know. > > I take exception to that :-) Alls I know is that they are enabled by > default. > > Run "ncrcontrol": > > # ncrcontrol > T:L Vendor Device Rev Speed Max Wide Tags > 0:0 SEAGATE ST31055N 0318 10.0 10.0 8 4 > 1:0 SEAGATE ST31055N 0318 10.0 10.0 8 4 > 2:0 SEAGATE ST31055N 0318 10.0 10.0 8 4 > 3:0 SEAGATE ST31055N 0318 10.0 10.0 8 4 > 4:0 SEAGATE ST31055N 0318 10.0 10.0 8 4 > > I just a day or two ago sent a note to Stefan asking about the maximum > number of tags allowable... it looks to me as though IF you are using Well, and he didn't have time to even read your mail before today ... (Sorry) The NCR driver needs a command control block per outstanding request, which contains information about the command to execute, and especially the scatter/gather table. This table allows for 33 segments (generally sufficient to describe a 64KB transfer, if the NCR is expected to handle disconnect/reselect on its own, with no host CPU intervention). The total amount of state storage is some 300 bytes per simultanously outstanding command. If I expect to have 4 disk drives connected and to have each of them use 8 tags, there must be command control blocks for 32 commands, and thos ewill consume 10KB of RAM. The other limit is introduced by the fact, that the NCR can signal the CPU the completion of some command, but can not easily let it know, which command finished. The CPU has then to check all outstanding commands blocks, and will complete those that are no longer marked as BUSY. The CPU has to scan all active command structures, and this makes the time per interrupt grow with the number of outstanding commands ... > the Adaptec stuff that it defaults to 8 tags. I really don't know > anything much about the real technical details of this stuff though.. I've seen slightly better throughput results with 8 tags, but this is not true for all disk drive models. 4 gives most of the advantage that can be had by using tags (at least 95% of the max. performance) and is a good choice, IMHO. Use "ncrcontrol -s tags=8" to make all drives use up to 8 tags, or try with 16 (the currently implemented hard limit). The driver does not work too well, if the disk drive does not support as many tags. And going from 8 to 16 tags did reduce performance in just about every test I tried, so it does not appear to be to low a limit ... Regards, STefan