Date: Mon, 16 Mar 1998 15:17:54 -0600 From: Karl Denninger <karl@mcs.net> To: shimon@simon-shapiro.org Cc: scsi@FreeBSD.ORG Subject: Re: Any thought given to... Message-ID: <19980316151754.59416@mcs.net> In-Reply-To: <XFMail.980316132008.shimon@simon-shapiro.org>; from Simon Shapiro on Mon, Mar 16, 1998 at 01:20:08PM -0800 References: <19980316144134.46045@mcs.net> <XFMail.980316132008.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 16, 1998 at 01:20:08PM -0800, Simon Shapiro wrote: > > > 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? Correct. > > 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 I don't know. I haven't loaded a profiled kernel, and frankly, I'm not sure that would tell me much. I'm doing some testing against a RAID 5 configuration now which has a completely different load profile, and the results are positive there also, albiet quite a bit less dramatic. I was simply floored at the News machine differences; I hadn't expected anything like that. What I was really looking for was more resistance to faults (the current "sd" driver makes a f*awful mess of things if you get a bus error reported back or some kind of cable problem - ie: "unexpected busfree") and about half the time will either totally hose the data in transit or hang the entire machine. The monster performance differences were unexpected, but certainly not unwelcome! FreeBSD doesn't report percentage of time in an I/O wait, but if you have things in "D", you can assume that's where all the "idle" time is going..... -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost 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?19980316151754.59416>