Date: Sun, 21 Feb 1999 14:02:04 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: mjacob@feral.com Cc: ken@plutotech.com, grog@lemis.com, paulz@trantor.xs4all.nl, freebsd-current@FreeBSD.ORG Subject: Re: Slow seq. write on Seagate ST36530N Message-ID: <199902212102.OAA20768@panzer.plutotech.com> In-Reply-To: <Pine.LNX.4.04.9902210218100.1414-100000@feral-gw> from Matthew Jacob at "Feb 21, 1999 2:20:51 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote... > > > > > > It sounds like a good idea, and it is. What I want to see is scsi_da use > > > this automatically. I have never liked the "punch it, Chewey!" approach > > > CAM has been taking..... > > > > What do you mean "scsi_da use this automatically"? > > > > All of the tagged queueing stuff is controlled in the transport layer. > > What are you proposing that the DA driver do? > > > > It is up to a target driver to control properties of performance and > reliability on the target device and to mediate between filesystems and > that device. The da driver should be checking for and adjusting > performance criteria based upon this. Whether it is now currently > mistakenly placed in the transport layer (tags are a property of > parallel SCSI- tags, qua tags, are not the issue, but the number of > parallem operations at a time is) is not the issue. I think it would be very difficult for the DA driver, or any other peripheral driver to accurately adjust the number of parallel operations based on performance. How does the peripheral driver know whether the underlying device is being "pounded" or just "pinged"? What may be "pounding" for one device might simply be "pinging" for another. Even if you measured latency for each command, there's no way to know the reason for the latency of any given command without in-depth knowledge of the device in question. (e.g., there's no way to know whether a higher-than-average time to completion is the result of an overloaded device, or the result of something like a thermal recalibration...) I think the best we could hope for is some sort of userland benchmarking process that would establish roughly the "best" number of transactions for a given device. Based on what I've seen, I would say that this would generally be either 1, or whatever we determine automatically from the device's queue full responses. There are, I think, relatively few devices that should be in the land in between those values. (e.g., device X doesn't return queue full until we reach 48 transactions, but its performance really stinks if you go above 30 transactions) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902212102.OAA20768>