Date: Thu, 05 Jun 1997 11:41:39 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Kenneth Merry <ken@housing1.stucen.gatech.edu> Cc: freebsd-smp@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: 2xPP200 vs 2xPP150 Message-ID: <199706051643.KAA28909@pluto.plutotech.com> In-Reply-To: Your message of "Thu, 05 Jun 1997 03:10:10 EDT." <199706050710.DAA09276@housing1.stucen.gatech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
[About the Quantum Atlas II] >upgrade the firmware on your drive from LXQ1 to LXY4. > - Justin said a little while back that there are bugs with the older > firware revisions on at least the Atlas II, and I think the Atlas I > that cause tagged command queueing to not work properly. I was able to > successfully upgrade my firmware, and I know that Satoshi has done it > as well. (he has a XP34550W as well) The Atlas I would return QUEUE FULL at very low tag counts with firmware revisions below L915. With L915, it seems that using up to 31 tags is possible. As for the Atlas II, Quantum still hasn't addressed the QUEUE FULL problem. On my test "CAM SCSI" system: da4 at ahc0 bus 0 target 4 lun 0 da4: <QUANTUM XP39100S LXY4> Fixed Direct Access SCSI2 device da4: Serial Number PCB=2011303101 ; HDA=189704332253 da4: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da4: 8682MB (17781520 512 byte sectors: 255H 63S/T 1106C) (da4:ahc0:0:4:0): tagged openings reduced to 30 (da4:ahc0:0:4:0): tagged openings reduced to 22 (da4:ahc0:0:4:0): tagged openings reduced to 18 (da4:ahc0:0:4:0): tagged openings reduced to 16 (da4:ahc0:0:4:0): tagged openings reduced to 8 (da4:ahc0:0:4:0): tagged openings reduced to 6 (da4:ahc0:0:4:0): tagged openings reduced to 4 This happens simply by performing a: cd /mnt; dump 0f - /usr | restore rf - Now, at least with the new CAM code, receiving QUEUE FULL status from a drive will only reduce performance since it takes time to handle the QUEUE FULL condition and it can result in a reduction in the number of transactions allowed to be queued to the device. In the current SCSI code, things are quite fragile, and repeated QUEUE FULL status can cause an infinite loop in the kernel. According to Quantum, the Atlas II's firmware should be able to handle up to 256 tags at a time. Unfortunately, they seem to hold on to the resource necessary to queue a transaction on writes until they are completely written to the media even though the drive may return good status long before this happens. This makes it really tough for the SCSI system to determine what is an appropriate tag count to use. The current algorithm used in CAM is to simply truncate the number of "openings" when a QUEUE FULL is encountered to the number of transactions that are still left on the device (e.g. if the 15th transaction caused a queue full, we'll drop to 14 and not queue any more to the device until we drop below that number). It may be that, for drives like the Atlas II, better performance could be achieved by adding some hysteresis on the count along with a delay in releasing new transactions, but I don't know how worth while the added complexity would be. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706051643.KAA28909>