Date: Mon, 16 Mar 1998 13:43:25 -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.980316134325.shimon@simon-shapiro.org> In-Reply-To: <19980316151754.59416@mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16-Mar-98 Karl Denninger wrote: ... >> What you rfer to as RAID controllers, are, in fact a ``RAID box'' which >> you >> access via another HBA. Right? > > Correct. In that case, you are right; Your communications on the SCSI bus heavily depends on the HBA, etc. Tagging could play a major role. It also depends on what your RAID box does with untagged commands. From your described sensitivity, it appears that host based tagging is important. On the DPT, it makes little change that I can see. ... > 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 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. > 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 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.980316134325.shimon>