Date: Mon, 16 Mar 1998 14:41:34 -0600 From: Karl Denninger <karl@mcs.net> To: shimon@simon-shapiro.org Cc: scsi@FreeBSD.ORG Subject: Re: Any thought given to... Message-ID: <19980316144134.46045@mcs.net> In-Reply-To: <XFMail.980316120755.shimon@simon-shapiro.org>; from Simon Shapiro on Mon, Mar 16, 1998 at 12:07:55PM -0800 References: <19980316124614.64072@mcs.net> <XFMail.980316120755.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 16, 1998 at 12:07:55PM -0800, Simon Shapiro wrote: > > > Tapes do in fact work in the default density (which is where most people > > use > > them). I know 'cause I'm doing it :-) > > Good. > > > CDs appear to work, including autochangers (!). So do removable media > > (which is problematic with the existing layer). > > Even better. > > > There ARE host adapters which are missing - a lot of them. > > I know I would like to move the DPT driver to CAM. Just where is the time? > > > That's why I suggested making it a compile-time (or even CVS extract > > time) > > option. Compile time would be even better, but that's admittedly a PITA; > > extract-time might be a lot easier to do. > > This is Justin's baby. He should make the decision. I'll voite for > compile time option. > > > I agree that its not "prime time" at this point. But it is a major > > improvement in a number of areas over the old drivers, including > > performance levels under real load profiles. > > Although I was born in Tiberias and not Missuri, I'd concur with you when I > see it. I see no under-load failures with the existing code. The only > thing visible in my corner is dropping interrupts. This I am sure comes > from elsewhere (fast_intr and such). > > Simon 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. 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. 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. 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. 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. -- -- 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?19980316144134.46045>