Date: Mon, 16 Mar 1998 13:20:08 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Karl Denninger <karl@mcs.net> Cc: scsi@FreeBSD.ORG Subject: Re: Any thought given to... Message-ID: <XFMail.980316132008.shimon@simon-shapiro.org> In-Reply-To: <19980316144134.46045@mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16-Mar-98 Karl Denninger wrote: ... > You should try it. I built a second source tree and applied the patches > (a couple of quick fix-ups were required) and it works very well. Knowing who wrote it, I trust it works real well. I have no hardware on which to test it, until I convert a DPT to CAM. > The primary benefit is intelligent management of tag queueing; this can > make > for huge performance increases on very busy systems. The old driver is > somewhat stupid about this, and it shows. I had this discussion with justin before. The DPT firmware does a rather good job at queue taggin. the overhead of pushing individual commands into the DPT, vs. tagged requests is at the noise level. I am sure it (good tagging) will be a boon for other controllers, though. > If you look at an SCSI device that actually allows you to see what is > going > on (ie; the CMD RAID controllers) you'll see that the old driver, under > heavy load, aborts tags on a somewhat-regular basis. While this doesn't > destroy anything, it is symptomatic of the driver being too dumb to know > what the "right" number of outstanding tags should be, and perhaps other > points about management of them in general. What you rfer to as RAID controllers, are, in fact a ``RAID box'' which you access via another HBA. Right? > CAM doesn't do this - at all. In fact, CAM leaves no turds in the SCSI > event logs on our CMD RAID systems - something the standard drivers > cannot claim to do. > > Raw, single-process I/O rates are comparable. Where CAM wins big is on > very > busy systems with lots of small I/Os to unrelated places - exactly where > tagged queueing is most useful. > > Our news system is running a CAM kernel now. It pulls raw I/O rates > (when > idle) of ~17MBps through the disk pack (I've posted about this before) > with > either set of drivers. > > With the old driver, the system was starved for SCSI I/O. Not due to > lack > of transfer rate - due to inelegant ordering of I/O operations. News is > a > monster on the disk system - it has near-zero locality of reference, and > across 30GB of data, no amount of cache helps much. True. I have observed the same thing. > CAM has basically fixed this. Response time has fallen 70% for posting > and > we are now limited by Ethernet cable bandwidth (!) into the same machine. > I'm going to swap that card out for a 100TX one and plug it into the > other > side of our switch soon. > > As far as I can tell, this looks to be entirely due to better tag > queueing > management in the CAM driver. I belive the new code is an improvement. Is it exclusively due to one factor? Simon 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?XFMail.980316132008.shimon>