Doug Ledford wrote:
>
> Robert Frey wrote:
> >
> > "Justin T. Gibbs" wrote:
> >
> > > I agree with all that you've said, but you've left out the most compelling
> > > reason that domain validation is necessary: SCSI->SCSI bridges. Although
> > > a SCSI-SCSI bridge may support some LVD transfer speeds, it may not support
> > > all of them. The only way to find out is to perform domain validation.
> > > For instance, I have no idea if the currently available LVD->SE/LVD bridges
> > > understand DT transfers.
> >
> > That's a good point along with Dan's legacy SCSI backplane example. But I can
> > argue this is a misconfiguration.
>
> OK, this has gone beyond a usefull debate. If you want to take the high road
> that anything other than a perfectly sculpted SCSI bus that does everything
> perfectly is a misconfiguration, and that no external factors are allowed to
> influence the SCSI bus, and that everyone must buy matched hardware all at one
> time instead of upgrading piecemeal, etc., then feel free. I, on the other
> hand, have to worry about all the times that users email me with problems that
> *I* know are SCSI bus related problems (termination, cable length, cable type,
> cable proximity to other emf producing devices such as active IDE cables,
> backplanes that don't grok the latest signals but do at least know LVD and
> could therefore be a cause of problems with DT transfers, etc) but that take
> their system down. If even one of those users is kept running long enough
> that the problem *isn't* an "I'm dead in the water, save me!" issue and
> instead they can limp by, then that means I'm not busting my ass having to
> take care of it on their time scale. That's what matters to me. And to date,
> there have already been multiple cases of this being true where the system
> backed all the way down to async mode as needed, but at least it kept running
> and I could help them solve their problem as *I* had time to do it.
Doug,
Since this thread "has gone beyond a usefull debate", allow me
to divert it to a performance issue with this recent posting
on the SANE newsgroup. Has anybody else noticed any performance
degradation since the big changes started in the scsi subsystem
(around lk 2.3.30)? [sg and the aic7xxx driver also figure in
this report.]
Doug Gilbert
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Subject:
speed of the the latest cvs (yesterday) and Kernel 2.3.46
Date:
Thu, 24 Feb 2000 22:27:06 +0100
From:
Rene Rebe <[EMAIL PROTECTED]>
Reply-To:
[EMAIL PROTECTED]
Hi, out there!
/* I had to resend this, because I was subscribt with my old eMail-adr
... I hope it will only apear once ;-) */
Because of the major improvements of the generic scsi interface in the
2.3 kernel series (I thought there are some ...) I updated my server
to the 2.3.46 Kernel and recompiled sane (yesterday-cvs).
I wanted to make some benchmarks for my avision-backend web-page and
noticed that this new combination is MUCH SLOWER!
The Avision is connected to an Adaptec AHA-2940-U with pentium 120.
With 2.2.12 and a end-january-cvs an a4 - 400dpi - color scan took
180s.
With 2.2.46 and the yesterday-cvs the same scan took 236s! Which is
56s (31%) slower ...!
Does anyone has the same problem?? Or maybe know what could be wrong??
(I hope the english is "readable"...)
k33p h4ck1n6 Ren�
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
