-------- Original Message --------
Subject: Re: [Networker] 5 questions on library pickers and devices?
Date: Fri, 06 Feb 2004 19:05:48 -0500
From: George Sinclair <george.sinclair AT noaa DOT gov>
Reply-To: george.sinclair AT noaa DOT gov
To: Tim Mooney <mooney AT DOGBERT.CC.NDSU.NODAK DOT EDU>
References: <4023E782.55A59098 AT noaa DOT gov>
<Pine.OSF.4.58.0402061439450.498933 AT dogbert.cc.ndsu.NoDak DOT edu>
We have visually confirmed that the robot is indeed first on the bus and
drives 1 and 2 are next, so following the SCSI cable from channel A on
the host Adaptec card back to the library, you hit the robot then drive
1 and then drive 2 which is then terminated. There is an external flat
cable daisy chaining the robot to drive 1 and then drive 1 to drive 2. I
have not noticed a slow down in speed on the drives, and as strange as
it might seem, the inventory operation now acts better than it did when
the picker came last and was terminated and had the highest ID. When I
say better, specifically I mean that if I delete the jukebox, re-run
jbconfig to recreate it, I can then turn on the bar code reader and when
I inventory the tapes (not new ones), NetWorker doesn't load the tapes.
This is the behavior you'd expect, but before, with the picker was last
on the chain and had the higher ID, it insisted on loading the tapes.
Now, go figure! This has me wondering if the "dissapearing act" will
stop.
I should note, however, that we have not done any heavy backups since
implementing this new strategy. We might well discover that it would be
best to do as you said and change the ID of the picker back to 6,
leaving the drives at 2,3,4 and 5, but maybe leave the picker physically
first on the bus. That would be interesting and would at least get us
out of any hot water with the picker not having a high enough priority
to respond to commands. Come to think of it, the ATL libraries have
always been rather slow to respond to picker commands when backups were
running, but that may also be due to the load on the server. Hmmm ...
Well, once we do get this solved, I'm gonna pop some Champagne.
George
Tim Mooney wrote:
>
> 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.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
