Date: Sat, 21 Feb 1998 11:02:27 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: "Richard S. Straka" <straka@home.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, scsi@FreeBSD.ORG Subject: Re: very slow scsi performance Message-ID: <199802211805.LAA17699@pluto.plutotech.com> In-Reply-To: Your message of "Sat, 21 Feb 1998 09:32:14 MST." <34EF018E.41C67EA6@home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> The Atlas I did pretty well. The Atlas II has a nasty problem with >> the queue full condition that can render tagged queuing useless >> unless your queuing algorithm is smart. I'm hopeful that they will >> fix it for the Atlas III, but even if they don't, CAM knows how to >> deal with this particular type of problem. >> >> -- >> Justin > >With my Symbios 875 card, I was getting scsi errors indicating the >tag queue was full on my Atlas 2 drive. After reading the Atlas 2 >manual, I found that the WCE (Writeback Cache Enable) bit was set by >default. With this bit set, the drive returns a GOOD status and a >TASK COMPLETE after fetching the data and storing it in cache memory. >If this bit is not set, GOOD status and TASK COMPLETE is returned only >after the data is committed to the media. Yes. That is exactly how the cache is supposed to work and it should have no effect on the number of outstanding transactions the controller can maintain to the drive. >With the WCE bit set, it looks like the NCR driver kept sending more >TAGS until the cache memory filled up. I would expect the cache to fill up and that this might postpone future write requests, but it should not cause future write requests to fail. No other drive I've tested has this behavior. I assume these "other drives" use separate data structures to keep track of open transactions to the initiator, and cache transactions that are waiting to hit the disk. This means that you can allocate a static amount of memory for transactions the initiator knows about and regardless of how your cache fills up, always service up to a static number of initiator transactions at a time. >When I set the WCE bit to 0, >the scsi errors went away and as long as the number of tags is set high >enough (>16) performance did not seem to be adversely effected >according to bonnie benchmark runs. Not using the write cache really hurts your write latency. You shouldn't have to turn off the cache to make a drive with a coherent cache work properly. This is simply a drive with poorly designed firmware. BTW. CAM is much more aggressive in the way it manages it's queues and tags. It will happily queue up to 64 transactions (this is the current default, but it can easily be set higher) to a drive and dynamically adjust that number depending on how the drive responds. With the Atlas II, a simplistic algorithm will cause the OS to drop down as low as 2 transactions if you hit the drive with the right I/O pattern (say a restore from another disk). To combat this, CAM allows you to specify a minimum tag count (currently set at 24 for Atlas IIs) so that even in the face of temporary queue shortages, you can still keep the transaction count at something reasonable. Of course, the OS still pauses until at least a single transaction completes before sending more when a queue full occurs, but seeing queue fulls at all wastes SCSI bus bandwidth. >regards, > >Richard Straka > -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802211805.LAA17699>