Date: Mon, 16 Mar 1998 15:49:40 -0600 From: Karl Denninger <karl@mcs.net> To: shimon@simon-shapiro.org Cc: scsi@FreeBSD.ORG Subject: Re: Any thought given to... Message-ID: <19980316154940.13918@mcs.net> In-Reply-To: <XFMail.980316134325.shimon@simon-shapiro.org>; from Simon Shapiro on Mon, Mar 16, 1998 at 01:43:25PM -0800 References: <19980316151754.59416@mcs.net> <XFMail.980316134325.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 16, 1998 at 01:43:25PM -0800, Simon Shapiro wrote: > > On 16-Mar-98 Karl Denninger wrote: > ... > > 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. > > In the DPT driver, there is a detailed set of non-veasive (well, not vry > invasive) metrics that may help you profile the SCSI I/O through the > controller. The firmware on the card collects its own set of metrics. > Both are available to userspace, in realtime. I can get into the RAID box from the serial port and see an awful lot of information. One of the interesting things is that before CAM there was no way I could ever "hurt" the processor on the RAID side - that is, there was always 50% or more of the RAID system's CPU available. Now I frequently see the available CPU down in the 10% range! Needless to say that's a pretty good indication of the efficiency change in the driver. The I/O mix is pretty well understood on the news machine anyway (its just all over the place :-). When you can basically max a MIPS processor with hardware acceleration for the parity computations you know you're cooking with gas :-) > > 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! > > Yes, I saw that nasty tantrum before. Well, the place I got bit by it wasn't on the news machine (where its not really all that big a deal). The "prophylactic" value is significant though. If you get an error on an I/O request there is simply no reason to barf the *rest* of the queued I/O! That's what was going on - it wasn't the single request that got hosed without being retried, but literally everything in the chain that hadn't yet made it to the RAID controller that was being aborted. That can be a *lot* of data; if you're unlucky you end up with a system that won't fsck when it comes back up. > > 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..... > > Again, the DPT driver collects these very metrics very well. A good > example, understood by most, is ``make world''; the DPT is virtually idle > during this procedure. Even with -j12. > > In other tests, I can only saturate the controller with very specific I/O > profiles. > > All you managed to do is make me eager to re-write the driver for CAM. > Thank you very much! :-) > > Simon No problem at all. -- -- 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?19980316154940.13918>