From owner-aic7xxx Tue Aug 25 02:23:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA28738 for aic7xxx-outgoing; Tue, 25 Aug 1998 02:23:00 -0700 (PDT) (envelope-from owner-aic7xxx@FreeBSD.ORG) Received: from fjellnett.fjellnett.no ([194.248.82.140]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA28728 for ; Tue, 25 Aug 1998 02:22:58 -0700 (PDT) (envelope-from helge.hafting@daldata.no) Received: from HELGES_PC ([194.248.82.201]) by fjellnett.fjellnett.no (Netscape Messaging Server 3.01) with SMTP id 363 for ; Tue, 25 Aug 1998 11:16:39 +0200 From: "Helge Hafting" Reply-to: helge.hafting@daldata.no Date: Tue, 25 Aug 1998 08:56:25 +0100 To: aic7xxx@FreeBSD.ORG In-Reply-To: Subject: Re: Micropolis 3387NS and Tagged Queueing X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b48 Message-ID: <19980825091636515.AAA261.363@HELGES_PC> Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In , on 08/24/98 at 12:51 AM, Brian Ristuccia said: >Does anyone know the maximum safe queue depth for this drive and my >aic7xxx controller? The source use a default depth of 8, because "any device can handle that." The documentation also state that there's no need for more than 32. I will try 32 for all devices when this start working. The kernel will reduce queue size after a while and give a message if it isn't used. This can then be specified as the new maximum. I believe the max queue for the aic7xxx driver is 256, which ought to be enough. I don't know what happens if the device doesn't support the queue length, there will probably be some kind of failure. Should be easy enough to find the limit by experimentation - if there's an useable error message. >It looks like tagged queueing is currently disabled. Any idea what the >performance penalty is for this? With queuing: Several commands are sent to the device. It will process the next command as soon as the previous complete. Some devices will even overlap stuff - i.e. start reading the next requested block into buffer memory *while* the previous requested block is being transmitted to the host adapter. This does not happen without queuing. A device will complete the current command, and then wait for the next one before anything more happen. The wait will probably be a short one, as the driver should send the next request pretty fast. It may hovewer be busy communicating with some other device. Also, you don't get the benefits of overlapping requests on advanced devices. I think the advantage of tagged queuing is biggest when there's lots of heavy i/o going on, involving several devices. Such as access to several drives in a raid system. Accessing fragmented files should speed up too. Helge Hafting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-aic7xxx" in the body of the message