Date: Thu, 30 Sep 1999 00:13:09 +0200 (MET DST) From: Gerard Roudier <groudier@club-internet.fr> To: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, Kevin Street <street@iname.com>, scsi@FreeBSD.org Subject: Re: sym driver 0.3.0 Message-ID: <Pine.LNX.3.95.990929235914.1001B-100000@localhost> In-Reply-To: <199909292019.OAA01634@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Sep 1999, Justin T. Gibbs wrote: > >Indeed it was that. I have fixed it yesterday when rereading the code an= d > >made SYM.0.4.0 available. I just reread the code after having posted my > >suggestion to look on the tags number and discovered the issue. I have > >stressed the change using LXY4 and it seemed robust and fits XPT > >expectations that reduces the device queue depth now. I had been confuse= d > >while testing the QUEUE FULL code the first time by the value 32 reporte= d > >by camcontrol versus 64 asked by the SIM. By the way, I never experience= d > >problem with LXY4 when starting with 64 tags under Linux and adjusting > >the tag depth when needed. When the write caching is disabled on LXY4, t= he > >device can accept more than 32 tags without returning QUEUE FULL. May-be > >FreeBSD-CAM is a bit too conservative about quircky devices. >=20 > It has always been my intention to change the tag reduction algorithm to > be more adaptive than the current approach. In order to deal gracefully > with resource shortages in multi-initiator situations, the tag algorithm > should attempt to raise the number of tags. Assuming this 'windowing' > code only occasionally incurs a QUEUE FULL, quirk entries for devices > like the Atlas II would not be needed. This is another entry on my > whiteboard. Reducing the device queue depth to the actual number of disconnected commands is fine as an immediate decision. Increasing the number of tags based on some simple criteria seems to be quite fine even for the quantum drives, at least in mono-initiator environments. For example, adding 1 to the queue depth every N good status received (N constant) seems good enough. I wanted to use N<100 but coded N=3D1000 under Linux.=20 Obviously there is room for far better heuristics that can use variable value for N based on the actual pattern of the QUEUE FULL conditions=20 compared to GOOD statuses received. Note that if you are good at dealing with LXY4 and friends QUEUE FULL status, you are probably excellent in this regard for any other device and may-be for ever. :-) G=E9rard. 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?Pine.LNX.3.95.990929235914.1001B-100000>