>
> On Fri, 9 Mar 2001, Mike Smith wrote:
>
> > Joe; it looks like you have some funny ideas about something that's not
> > actually very relevant. I assume that you have already gone and bought
> > Monster Cable(tm) SCSI cables, and that you have the special
> > oxygen-free-copper SCSI controller PCBs, because none of this is going to
> > mean anything unless you have.
>
> Pardon and sorry, Mike. It is rather your reply that looks funny to me.
It's meant to be funny. Telling someome straight up that they're being
silly isn't very amusing, so I like to improve things when I can.
> The number of SCBs in (both) the Linux and FreeBSD aic7xxx driver(s) is
> very relevant in my opinion given that it is just the maximum of SCSI
> command contexts the driver can handle (i.e. maximum number of outstanding
> IOs).
I'm not referring to the number being relevant, rather I'm referring to
the percieved need that Joe has to tune said number.
> > > I'd like to ask if anyone can share any knowledge about how/if the number
> > > of SCBs affects performace for scsi drives.
> >
> > If you don't have enough SCBs, you can't deliver enough commands to your
> > drive(s) to keep them busy.
>
> Being busy does not imply doing a good job. You can get a device full busy
> using only 2 simultaneous IOs for this device. Using more can allow the
> device to perform optimizations based on actual head positions and
> possibly coalesce data transfers when possible, for example.
That's a better way of putting it, for sure.
> > > Also I would like to be able to configure the number of SCBs that the scsi
> > > driver uses. With Linux this parameter for the aic7xxx driver can be
> > > configured via "make menuconfig" step of the kernel build process. Is
> > > there a similiar way to configure this varible for BSD? Or do I have to
> > > start hacking on the driver code?
> >
> > You can't do that. Firstly, there isn't a "SCSI driver", secondly there
> > are several different sorts of objects that map to what you, coming from
> > the Linux world, would call an SCB, and thirdly, the CAM subsystem
> > components have a much better idea than you do how many of these that are
> > needed, and will allocate them as necessary.
>
> You should have been more accurate here, in my opinion. Vague explanations
> are worse than no explanations at all, in my opinion.
I find this amusing, mostly because I'm usually asked to dumb down my
explanations so that people can understand them. 8) Your exposition does
of course give a much more detailed view of the issues.
> Btw, your reply let me think that you want to discourage people to hack
> our source code or to try to understand how it works. Colour me very
> surprised. :-)
Actually, quite the opposite. I'd much rather have Joe go look at the
source and tools himself than sit here and try to explain it all to him.
However, I'd take even money on a request like this being from someone
that is expecting everything else to be just like what he's already used
to, and the first step is just to convince them that that's not really
the case...
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
