> > In other words, any device on the chain will run no faster
> >than the previous device, so it would not make sense to place a fast
> >device after a slower one. Devices should be placed in order from
> >fastest to slowest, and if done this way, every device will run at its
> >proper speed, assuming good cable, length, etc. but not sure if this
> >logic applies to pickers, so here are my questions:
>
> Yes and no. If you're going to mix devices on a bus that talk different
> "speeds" *of the SCSI protocol*, you don't want a slow-talking SCSI device
> (let's say an 80 MHz Ultra2 LVD device) between the HBA and an
> 160 MHz device.
What? How is a SCSI device "in front of" another device going to affect
it differently from one that is "behind" it? It's all one big bus.
There's no device ordering here.
> More importantly, if you have devices that use different
> widths (8 bit vs. 16 bit vs. 32 bit), you don't want the 8 bit devices
> physically cabled between your HBA and the wider devices.
That's a separate issue. Yes, you certainly don't want non-wide cables
connecting wide devices.
> If your robot can talk the same speed and width of SCSI, just like all the
> other devices on the bus, then even though it's a physically slower device,
> it doesn't matter where you put it physically on the bus. It doesn't need
> to be further away in the chain from the HBA.
> Remember that most SCSI devices disconnect when they have something to do
> that's going to take a while, thereby freeing the bus for other devices
> to talk.
In other words, when you're not talking to the robot, even thought it
might be slower, it's not slowing down the bus.
> >1. In a typical LVD tape library, will having the picker first on the
> >same bus as the tape drives slow down the drives?
>
> If the picker speaks a slower version of the SCSI protocol, then yes,
> it very likely will. If it speaks the same version of the SCSI protocol
> as the devices, then *no* it will not.
However, that shouldn't matter much unless you're talking to the robot a
lot. In most backup environments, the robot is only communicating a
fraction of the time. It shouldn't significantly affect tape speeds.
> >I see the following during boot up (we're running Linux RedHat):
> >
> >Slot Ch ID LUN Vendor Product Size Sync Bus
> >------------------------------------------------------------
> >06 A 0 0 STK L80 ASYN 8
> >06 A 2 0 SEAGATE ULTRIUM06242-XXX 80.0 16
> >06 A 3 0 SEAGATE ULTRIUM06242-XXX 80.0 16
> >06 B 4 0 SEAGATE ULTRIUM06242-XXX 80.0 16
> >06 B 5 0 SEAGATE ULTRIUM06242-XXX 80.0 16
> >05 A 0 0 ATL 6220050 ASYN 16
> >05 A 2 0 Quantum Super DLT1 80.0 16
> >05 A 3 0 Quantum Super DLT1 80.0 16
> >
> >2. What do the terms: 'Sync' and 'Bus' refer to?
>
> Sync means synchronous, all the devices that have a number mean that
> they're capable of talking *synchronously*. The 80.0 is the MB/s the
> device is capable of using the SCSI bus for (but the physical
> properties of the tape drive would never actually let it do that, it's
> just *capable of* synchronous data transfers at that rate).
> I can't remember the exact reasoning, but synchronous communication is
> faster.
It's because it can send several bytes of non-acknowledged data (like
TCP windows). Async must wait for every byte to be acknowledged. Much
slower for the same data rate.
> ASYN means asynchronous, and for reasons I've forgotten, it's not as
> fast as synchronous. The robots send and receive so little data that
> it doesn't matter for them that they operate only in async mode.
Correct.
> Bus means how wide a bus the device supports. All of your devices support
> the 16 "bit" flavor of SCSI *except* your STK robot, which only supports 8.
> When you mix devices 8 bit and 16 bit, you need to be careful about bus
> ordering. You generally want the 8 bit device(s) physically "past"
> the 16 bit device(s) on the bus. You also need to be sure that the 8 high
> signal lines are terminated, at the point where your 16 bit devices end
> and you 8 bit device(s) begin. This is generally handled by your cable,
> so there's usually nothing for you to worry about, as long as your 8-bit
> devices are "past" the 16 bit devices on the chain.
The physical location shouldn't matter at all unless the cables are
different.
--
Darren Dunham ddunham AT taos DOT com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
