From owner-aic7xxx Tue Mar 12 13:11:55 2002 Delivered-To: aic7xxx@freebsd.org Received: from scotty.rfa.org (scotty.rfa.org [207.123.167.15]) by hub.freebsd.org (Postfix) with ESMTP id 4E54E37B404 for ; Tue, 12 Mar 2002 13:11:51 -0800 (PST) Received: from rfa.org (peter.rfa.org [207.123.167.16]) by scotty.rfa.org (8.11.6/8.11.6) with ESMTP id g2CLBld10063; Tue, 12 Mar 2002 16:11:47 -0500 Message-ID: <3C8E6F13.979EB689@rfa.org> Date: Tue, 12 Mar 2002 16:11:47 -0500 From: Eric Dantan Rzewnicki Organization: Radio Free Asia - NIS X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Justin T. Gibbs" Cc: aic7xxx@FreeBSD.ORG Subject: Re: performance issues: linux aic7xxx, 29160, Radion IFT-7200 References: <200203082247.g28MliI80927@aslan.scsiguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello again, Adjusting the tagged command queuing value hasn't improved performance as measured with hdparm -t. Working with the 2.4.18 kernel, aic7xxx version 6.2.5 and queue depths ranging from 0-32 I have consistently gotten results in the range of 13-16 MB/s using hdparm -t. With the old 5.2.4 driver hdparm -t gives results of 47 MB/s. Is there something else I can do to try to get better performance with the new driver? You made a distinction between sequential and non-sequential workloads. This raid is currently 610GB. We intend to use it for storing mp3 archives of our broadcasts. Each file is typically around 7MB. The workload on the raid will be mainly reading and writing these mp3 files. To my mind this means the workload will largely be sequential...But, I'm not sure that I'm thinking clearly about this issue. Given are intended use of this raid, what advice do have with regard to what kind of performance I should be trying to achieve and how to measure it? Is hdparm a good enough test? Thank you for any help you can give, ERic Rz. "Justin T. Gibbs" wrote: > > >As I understood it based on the configure options and output from the > >driver via dmesg (both of which I may have _mis_-understood) the old > >driver leaves tagged queuing disabled by default. > > Looking at the results of /proc may be a better way to tell. > > >I attempted to turn off tagged command queuing by passing > >aic7xxx=tag_info:{{255,255}} at the boot prompt. This resulted in tagged > >queuing depth being set to 253. > > You need to use 0 with my driver. The README you looked at is for the > old driver. You can also disable tags in your kernel config. > > If all you want is sequential performance, disabling tags may be > beneficial on some really lame devices. In the more typical, non-sequential > workloads, tags are a godsend. > > -- > Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message