Component Order in a SCSI Chain

The article on SCSI component order generated some excellent feedback and dialogue. The following were written by Scott L. Barber of SERKER Worldwide, Inc., and Keith Bumgarner of MacInformed <http://www.macinformed.com/>, the author of the original article.

Scott writes:

I suppose I should have reread the SCSI article before replying to this thread, but I'll jump in on some key statements from his (Keith's) response. In essence, and in most practice, he's right. I just cannot help but bring FireWire and SCSI protocols, as well as DNS/BIND interpretations, into the fray in my own interpretations, and since we're increasing the technical knowledge of the readers to incredible levels beyond High School Diplomas, we might as well go all the way.

One of the constants of DNS/BIND is the notion that a subnet has priority in it's numbering system. Given a division of 16 numbers (called /24 in DNS), the highest priority is the lowest number of the first bank of 16. i.e. let's take a 10.0.0.0 Class A network and peel off the first 16 numbers for a router.

If we make the router 10.0.0.1, and a secondary email box 10.0.0.2, the secondary email box will have a lower routing priority than the router will. Create a DNS box, place it at 10.0.0.17, and because it is the BEGINNING of another subnet, in the "highest priority position", it will have a higher priority than the 10.0.0.2 machine, but not the 10.0.0.1 machine because of the design of the subnetting of the 10.0.0.0 class.

Why am I saying this? And why possibly am I choosing the lowest number instead of the highest? Well, it's been a long time since I've read DNS bind, so that the numbers might actually be 10.0.0.16, and 10.0.0.32, meaning priority is on the end, but that technicality of forgetting the direction of priority isn't really important - it's not crucial to the argument (so if you have a DNS/BIND book from O'Reilly available, you might double check this).

The crucial problem is this - SCSI uses a similar -- hard coded - priority protocol, that Apple chose to ignore several years ago. Well, they might not have ignored it . . . they have a damn good explanation for why they did what they did . . . the point is, SCSI 7 is highest priority, and SCSI 3 is next, because it represents the "subnet" of the SCSI chain. Putting a CD in this most reliable secondary spot really helps, especially if the CD is low buffered. We're not talking about cabling, termination lengths, anything like that - we're talking about how the controller maps it's devices.

So in a priority map, SCSI shows the following:

7 3
6 2
5 1
4 0

Ultra SCSI with 4-4bit chains follows the same routine, just setting the controller as 15 instead of 7, and creating four map lines instead of two. Only FireWire increases the Height of the chains.

So there are two concepts in direct conflict with each other, the issues below that he's correct about, dealing with physical cabling concepts and buffer sizes in SCSI devices, and the issues of priority when dealing with the ID address in the SCSI controller.

So this makes things a tad on the weird side. Apple chose SCSI 0 as the primary hard drive address instead of choosing either 6 or 3 - in reality 6 and 3 have damn near the same priority level - well - 6 is just a hair under 3, unless it's booted from. Apple chose 0 because of it's low level in priority - all other devices must clear buffers on shutdown, and since 0 is the last to respond, this correlates with the idea that the internal hard drive would be the last drive to report clear before a power down.

But enough about that . . . I want to address a few things about the SCSI controller itself, and the idea that hot swapping/power up/down SCSI devices in the chain isn't allowed. While that's a valid point, in practice it's often NOT an issue. Two solutions to the power up issue are: Make sure that a device that might be powered up or down is not the last device on either the internal or external chain. #2 . . . if you're going to be powering devices up and down, after completing use of the powerup device (scanner), make sure to shutdown to nvramclear the SCSI controller instead of a simple restart, which may not clear the controller map.

The risk of SCSI address damage to the partition map on a drive is real - but the risks depend on a dozen factors. The RF generation is a true real factor, and the termination is simply a "ping" by the controller to detect the time length of the SCSI chain - it will not (or should not) answer or respect any devices located a certain length beyond the calculated length of the SCSI chain. This prevents device echoes from coming back of the terminator (end of wire) and causing erroneous requests to the controller. Adding a hot device at the end of the chain is just dead wrong.

RAID boxes resolve this by having a hard terminator at the last device on the chain, thus always making the maximum length of the chain a fixed value, no matter what drives are installed in the box. This very easily fixes the termination issues, and resolves most of the damage from hot swapping due to addressing problems in the controller.

I do appreciate the fact that almost a year after the article was written that someone has finally decided to bring up these issues. It's important to note this, since NO ONE ELSE has brought it up, and that the answers given -- while not wrong, were simply not complete. I've noticed this trend in other articles too - where someone hits me for not explaining everything, and mostly I find it funny, and rather impressive, that something I said so simply absorbed by the readership as technically true gets caught after all this time - so it means the technical ability of the readership, and thus the overall readers of MacTimes are starting to migrate from the blind home user with a Performa 636 who wants to know about his maximum memory upgrade, to an engineering class user who wishes to banter about the very nature and process of creating computers and explaining in engineering terms the theoretical processes of each module of a computer motherboard. Whomever reads this should not interpret that Keith is wrong - in fact he's very correct. With this basis to start from (i.e. someone asking the right question finally), I'm more than happy to amend articles or clarify problems.

To be honest, I much rather prefer his style and interpretation of hardware SCSI issues to mine . . . my analogies are becoming archaic, and it's nice to have a fresh mind that's willing to share his own interpretations instead of relying on my statements - often riddled with automobile analogies and rushed in the desire to get answers - often mildly incorrect and questionable - out to the people. This is one "foundation" member of MacTimes who isn't insulted by being told he's wrong (more than often I'm turning to my employees and saying "YES!!! Finally!!! Someone caught it!!!"

I leave you with a content smile on my face, in the knowledge that I've finally been caught cheating on the test *grin*. Have a good one Dan, and Keith, and whomever else reads the MOTJ. And I know . . . someday . . . someone's going to demand the IEEE page on SCSI protocols that backs what I'm saying . . . and yes . . . I'm willing to rummage through the pages until I find it. But there are of course risks involved in that - the Bible does say everything . . . depending on how you read it . . . .

Scott L. Barber, serker@serker.com

CEO, SERKER Worldwide, a division of ContComm, Inc.

Providing Networking and Telecommunication solutions since 1984

Secure internet solutions through bulk encryption

-CNE Licensed|CISCO CID/CIT/IMCR/SNAM|Intel OAAF|MS-D

-ASE Cert|ASO-Hardware/Vendor Contact|BD-SMLUC

-Visit www.serker.com for more information

Keith responds:

Good stuff, Scott, and I agree with almost everything you say ("oh, why did he have to say 'almost' "), but I'm not sure your detail applies as much to single-ended, narrow SCSI-1/2 as it does to more recent renditions of the protocol(s). But who cares? I really don't and it would appear that both of us have something positive to add to all this.

Why, though, do these types of things (the back and forth spouting of the technical, I mean) often take on the look and feel of the shootout at the OK Corral? I've never had an ego (sounds like you don't either, or you left it somewhere) and I feel weary at just the thought of getting into some of these online testosterone "tussles" that I see sometimes in the newsgroups and chat rooms. Thanks (more than you know!) for not firing the escalation round over my head. I'm an old man (or at least feel like one) who prefers the company of my dogs and the serenity of my home and privacy.

You sound like a very smart, sensible guy that's been around the block a few times and knows as much from the streets as from the books - and a lot from both. I want to keep your name as a resource, and hope I'll hear of and from you again. You can contribute to or write anytime on our site you want to, just let me know. If you want to run an ad or want to expose some ideas, just let me know. I think you've got me figured out, but if you haven't, this certainly isn't about money or career for me, although I wouldn't want my clients to know that.

Thanks for the note.

F. Keith Bumgarner

keith.bumgarner@mac-techinfo.com

TechInfo,Inc.

http://www.mac-techinfo.com

(404) 843-0306