Am 18. Oct, 2000 schwäzte Rusty Carruth so:
> do you have anything else on the scsi chain? The slowest device will
> (I understand) drag all the other ones down with it. SO if you (like
> me)
That would be against the scsi spec. It does slow things down a bit, but
not the way you're thinking.
My example is a telephone operator that is conversant in many dialects.
Imagine scsi III ultra whatever to be a highly caffeinated new Yorker,
e.g. talks really fast :), and scsi I to be a Southerner taking his time
to chew on something as he talks about it, e.g. talks somewhat slower
than the overcharged New Yorker :).
The operator (scsi controller) speaks both fluently (presuming a newer
scsi controller). When talking to either of the devices the operator talks
at an equal speed. Since the operator can only talk to one at a time, the
Southerner doesn't keep the operator and New Yorker from talking faster
than the speed of sound because he's not in the conversatoin.
However, when the operator is talking to the Southerner, the Southerner
needs more time for the same query, so the operator isn't necessarily as
available as the new Yorker needs. If the Southerner isn't talking, the
New Yorker isn't affected by his presence in any way.
What this means is that if Kevin wasn't using his scanner, it wasn't
affecting the drive performance. That doesn't mean, however, that the
Linux scsi implementation is doing things right (in fact, from what I've
read on the scsi mailing list Linux isn't in many ways). I would think
that this dialect stuff can't be screwed up as that would massively
violate the scsi specs that have been in place for more than a decade.
Alan Cox complained greatly about the state of the Linux scsi code more
than a year ago. Many of the scsi devlopers seemed to agree that it needed
to be massively revamped. Lots of intracacies to work out. I don't know if
they've gotten anywhere. I also don't know if they were trying to remove
dust particles midair or were trying to shovel the pig manure out of the
kitchen...
Most of us have never seen a scsi I device. What we think of as ancient
scsi is actually scsi II (this coming from someone who knows scsi far
better than I). I should be able to connect a scsi I device on an
ultra-whatever controller and have them talk. Same with vice versa. Adding
any other scsi device shouldn't cause it to stop working (provided
acceptable cable lengths aren't exceeded).
That's something. Kevin, are your cable lengths OK? Are the devices far
enough apart, but not too far apart. scsi can be a really prissy about
such stuff. Sometimes it will work, but far from optimally. Are you
getting any scsi errors? You'd understand those better than I :).
> have an old scsi1 cdrom drive that only talks the slowest protocol
> you'll get stuck down at what, 10MB/sec? Those who know for sure feel
> free to correct me if I'm 'worng' (sic)
I think scsi I was something like a couple of MB/s. Never used a scsi I
device that I know of, but I think I have one (a scsi 5 1/4 floppy :).
> (And I'm surprised, because the same kind of tests that I've run on my
> scsi systems always show scsi better than IDE... Especially since
scsi is more reliable. Better hardware, less probs ( once you get cable
lengths, termination, scsi IDs, etc to work :). It does better with
multiple devices on the bus. It doesn't load the CPU as much. Look at the
amount of CPU used in Kevin's Bonnie results.
Try mirroring two scsi devices on the same controller and compare that to
two devices on the same ide controller :).
ide controllers are already on the board, so for 2 disks, it doesn't
necessarily take much of a performance hit for how Kevin has it setup.
Maybe also try two drives on same controller not mirrored and copy from
one to the other. These scenerios, however, don't affect Kevin's setup, so
apparently for his situation two ide drives is the best tool for the job.
I'm glad he did this. I didn't realize ide could match current scsi
capabilities.
Hasn't mattered for me thus far. Where I've needed performance ide didn't
even let me drop on enough devices, so scsi was the way to go :).
Another advantage for scsi: 15 devices, one irq :). That would probably
leave my devices a bit resource starved, though ;-).
cioa,
der.hans
--
#
der.hans@LuftHans.com home.pages.de/~lufthans/
www.Opnix.com
# Magic is science unexplained. - der.hans
(text/plain)