[8257] in linux-scsi channel archive
[was domain validation] scsi (lk 2.3.46) performance
daemon@ATHENA.MIT.EDU (Douglas Gilbert)
Sat Feb 26 00:46:13 2000
Message-ID: <38B768BD.854EFB41@interlog.com>
Date: Sat, 26 Feb 2000 00:46:37 -0500
From: Douglas Gilbert <dgilbert@interlog.com>
MIME-Version: 1.0
To: Doug Ledford <dledford@redhat.com>
Cc: linux-scsi@vger.rutgers.edu, rene.rebe@myokay.net
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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 <rene.rebe@myokay.net>
Reply-To:
sane-devel@mostang.com
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 majordomo@vger.rutgers.edu
