In regard to: [Networker] 5 questions on library pickers and devices?,...:
>I always thought that slow devices should always be placed last on a
>SCSI chain.
You're talking about physical ordering on the bus.
> 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. 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.
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. The HBA initiates something, the target (e.g. the picker, or
tape drive, or whatever) gets the command, responds and says "Ok, I'm
working on it", and then it disconnects. At that point, the bus is free
for other devices to talk. When the target has completed the SCSI command
and has something to report back to the initiator, it arbitrates for the
bus, and when it gets it, it sends its "results".
If you have a library where the picker speaks the same flavor of SCSI
as the drives, then the SCSI *IDs* are more important than the physical
cable ordering. Whenever there are two targets (devices) on the bus
that want the bus, which device gets to go first is decided based on the
SCSI ID of the device. The pecking order gets pretty complicated once
you get a bus with more than 15 devices, but for busses where all the
devices have IDs < 8, the priority order is from 7 (highest, generally the
HBA) to 0 (lowest).
If you place very busy devices at the higher SCSI ids, they may well
monopolize the bus. That's why you'll often see recommendations that you
put the less busy (or more I/O sensitive, such as older CD recorders) at
the higher numbers, and hard drives at the lower numbers.
With this in mind, you may want to have your picker be ID 5 or 6 on the
bus, so that when it wants to talk, it gets to. Otherwise, when your
tape drives are very busy, it may never get to say much. Your HBA (high
priority so it gets the bus when it wants it) might send it a command,
it gets the command, acknowledges it, and then disconnects for processing
the command. It processes the command, and then tries to arbitrate for
the bus, but the two tape drives are constantly winning arbitration,
because they're busy with WRITE commands (or whatever). The picker's
done what it needed to, but it can't get a word in edgewise, to report
back to the initiator (the HBA) that the command is complete.
>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.
>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.
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.
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 good news is, if you had the cabling or physical ordering incorrect,
I wouldn't expect all the tapes on the bus to report that they're
operating at 80.0/Synchronous. You would likely see some at only 40.0,
or perhaps even slower. If you have the time, swap cabling so that
the STK L80 is between a couple of the drives and the HBA, and see what
speeds they report on boot. I'm guessing the tape drives past the robot
will be at a slower speed (and/or identify as 8 bit devices).
>3. Notice in the above output that the 'Bus' value on the Storagetek is
>8, but the drives are 16. Unlike the ATL library, they do not match. Not
>sure what this implies, but if it has to do with speed then this has me
>a little concerned that maybe the STK picker might be forcing the LTO
>drives 1-2 (SCSI ID 2-3) to maybe lower their speed since it shares the
>same bus as drives ULTRIUM drives 1-2 and comes first on the bus?
It implies that the STK device doesn't speak the 16 "bit" version of the
SCSI protocol. The ATL picker does. It just means that it shouldn't
matter where the ATL picker is physically cabled on the bus. You're
right to be concerned about drives 1 and 2, if the picker is physically
between them and the HBA. Still, that they report 80.0/Sync means that
(for reasons I don't understand) they're operating at the speed you want.
Are you *sure* the picker is cabled between the HBA and those two drives?
>4. Some people suggest placing the picker on its own bus so in the event
>that one or more drives die and bring the affected bus down, the picker
>will not be subsequently affected. That's a good thing if you want to
>guarantee that the picker will continue to function if a drive dies or
>something weird happens on the bus that that the affected drive(s) was
>on. Seems it would be prudent, therefore, assuming you had a spare
>channel on the host adapter card, to put the picker on its own bus, BUT
>what I would like to know is this: Are there any arguments to suggest
>other reasons for doing this? People say picker generates little
>traffic, so maybe no need, but curious about why you'd put it on its own
>bus? Guess this gets back to my first question.
>
>5. Does it really matter what the SCSI id of the picker is as long as it
>doesn't duplicate another ID on the same bus or one that's reserved?
Yes, it very much does matter what SCSI id you choose. If you have the
picker at a low ID (like 0) and you have busy hard drives at ID 1 and 2
(say your /nsr directory in a mirror pair) and tape drives at 3-6,
your poor picker is only going to get to talk when everything else on the
bus hasn't arbitrated for the bus.
The rules for priority gets slightly more complicated for 16 bit SCSI
busses, but the bottom IDs (7 through 0) get priority over the top IDs
(8-15), but I can't remember what the arrangement is amoung the top IDs.
I want to say that priority is higher for lower-numbered devices in the
top 8, i.e. I'm thinking it's
highest priority -------------> lowest priority
7 6 5 4 3 2 1 0 8 9 10 11 12 13 14 15
I could have the top 8 reversed, though. In either case, even if the
bus goes to 32 bits, the 7 highest priority devices are from 7 to 0.
>I noticed on our two ATL libraries, the picker is ALWAYS id 0, the
>picker is always first on the bus, and the drives follow at like IDs 2,
>3 and 4. That's how they were set up originally. We didn't set them up
>this way, but they run like clock work. HOWEVER, on our Storagetek
>library, the picker was id 6 and came last on the first bus with drives
>1-2 being first. Drives 1-2 had SCSI ids 2 and 3 respectively. Drives
>3-4 shared the second bus at ids 4 and 5. We had nothing but headaches.
>We then changed the SCSI id of the picker to 0 and placed it first on
>the bus with drives 1-2 last on this same bus. Drives 3-4 remained on
>the second bus as before. We now notice that several things that were
>not working before are now working.
This is exactly the opposite of how I would have expected things to
work. Forget about the devices on channel B, since those wouldn't affect
what's on channel A. With the arrangement you've described, I would
expect that the LTO drives that share the bus with the picker would be
speaking in a degraded mode, because there's an 8 bit device between them
and the HBA.
What kind of SCSI connector does the robot have? Is it 50 pin, or 68 pin?
I'm puzzled why this configuration works better for you than the other
configuration you described. It's exactly opposite what I would expect.
However, as you've mentioned in other emails, you've having problems with
the STK L80 robot disappearing from the bus. This could be related to
the way you have things configured now. That some things work "better"
is a surprise to me. That you're having other problems is not. ;-)
Tim
--
Tim Mooney mooney AT dogbert.cc.ndsu.NoDak DOT edu
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
