linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Alexy Khrabrov <braver@pobox.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: Wide negotiation fails with 80->68 LVD adapter?
Date: Tue, 22 Oct 2002 13:03:16 -0400	[thread overview]
Message-ID: <20021022170316.GA31085@redhat.com> (raw)
In-Reply-To: <20021022161644.GA15234@angle.setup.org>

On Tue, Oct 22, 2002 at 12:16:44PM -0400, Alexy Khrabrov wrote:
> 
> Dan -- thanks.  I see those sca2lvd are mentioned as working by others
> trapped in SCA to 68 pin LVD switching.
> 
> So what is a "backplane"?

If you look inside one of the Dell servers that use SCA drives, or inside 
any external drive enclosure that uses SCA drives, they will have a green 
board that the drive sockets are all attached to and which is the carrier 
of the signals to all the drives.  That board is the backplane.  The 
primary difference between a backplane and a simple LVD<->SCA adapter is 
that backplanes are usually semi-intelligent devices themselves that don't 
just connect the drives to the SCSI bus, but in many cases have built in 
termination for the 68 pin LVD connection that is then routed into a 
bridge chip for the SCSI bus and then the other side of that bridge chip 
is then routed to the SCSI bus built into the backplane.  In that sense 
you have two SCSI busses and a smart bridge that connects them instead of 
being like the simple adapter which simply sticks the drive on the 
existing SCSI bus.  Keep in mind one of the things that determines bus 
quality is something called "stub length".  That's the total length of the 
various SCSI lines from the point at which they leave the primary SCSI bus 
until they terminate at the end point SCSI chip.

  SCSI Cable, terminator at end
      ^
      | __Stub Length__
      |/               \
      --+---+------------|
      | |   |            SCSI chip on drive
      | |   Connector on drive
      | LVD<->SCA Adapter
      |
      |
      
As you can see by my pitiful ASCII art, the stub length gets longer when
you plave an LVD<->SCA adapter between the drive and the 68 pin connector
on the cable.  Depending on the SCA adapter and the drive in question, you
could actually be increasing the stub length by a full 100%.  That
degrades the whole bus.  With backplanes, by putting all of the SCA
connectors directly on the backplane and running the SCSI bus through the
backplane instead of a cable, they can guarantee good signal quality.  By
using a bridge chip between the internal backplane and the external SCSI
cable, they again guarantee good signal quality inside the chassis
(because any possible poor signal traits on the external SCSI cable are
entirely electrically isolated away from the internal bus), and they also
guarantee that the signal quality on the external SCSI cable will not be
degraded by the internal signal traces since they are, again, totally
electrically isolated.  Of course, not all backplanes use electrical
isolation of the internal and external SCSI busses like this.  But, even 
without it, just having the connectors and the SCSI bus itself both inside 
of a printed circuit board instead of attached to a cable helps them 
control overall signal quality.


-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

  reply	other threads:[~2002-10-22 17:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-21  5:14 Wide negotiation fails with 80->68 LVD adapter? Alexy Khrabrov
2002-10-21 16:34 ` Doug Ledford
2002-10-22  2:00   ` Alexy Khrabrov
2002-10-22  5:13     ` Dan Jones
2002-10-22  3:24   ` Alexy Khrabrov
2002-10-22  5:30     ` Dan Jones
2002-10-22 16:16       ` Alexy Khrabrov
2002-10-22 17:03         ` Doug Ledford [this message]
2002-10-22 22:19           ` Alexy Khrabrov
2002-10-26 14:53             ` Alexy Khrabrov
2002-10-26 16:00               ` Doug Ledford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021022170316.GA31085@redhat.com \
    --to=dledford@redhat.com \
    --cc=braver@pobox.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).