Date: Tue, 25 Aug 1998 08:56:25 +0100 From: "Helge Hafting" <helge.hafting@daldata.no> To: aic7xxx@FreeBSD.ORG Subject: Re: Micropolis 3387NS and Tagged Queueing Message-ID: <19980825091636515.AAA261.363@HELGES_PC> In-Reply-To: <Pine.LNX.4.02.9808240050030.2330-100000@osiris.ml.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In <Pine.LNX.4.02.9808240050030.2330-100000@osiris.ml.org>, on 08/24/98 at 12:51 AM, Brian Ristuccia <brianr@osiris.ml.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980825091636515.AAA261.363>