Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news2.near.net!news.delphi.com!BIX.com!arog From: arog@BIX.com (arog on BIX) Newsgroups: comp.os.386bsd.questions Subject: Re: SCSI or IDE HD? Date: 20 Aug 94 08:33:00 GMT Organization: Delphi Internet Services Corporation Lines: 94 Message-ID: <arog.777371580@BIX.com> References: <salem.137.2E48D259@hauk.hsr.no> <graphix.776531255@spiff.cc.iastate.edu> <salem.147.776612144@hauk.hsr.no> NNTP-Posting-Host: bix.com I'll abstain from including the 200 odd lines that I'm responding to. Last items first. I found out recently that a friend has moved on to Quantum. Given her background... and that this is the kind of thing that she has done for atleast three other scsi disk makers over the years, it would not supprise me at all for them to bring out a 420 (or larger scsi-ii) with the only dif to the smaller drive being the micro-code and some tweaks to make it all work. Ok, now to let me long.gray.beard show... I learned the hard lesson back in the days of Cp/m about how sectors on a disk, floppy or hard, go 'bad' for no other reason than they have been written to too many times. Things have gotten better, the timing control is far better and the intersector_gaps are kept in a far better state than in the 'old-nights.' All well and good, but one very major considereation, esp where the drive is being asked to 'swap' is ability to retstore those 'gaps' to a virgin state as the drive ages. The *major* cost difference between SCSI and IDE is the electronics that are shipped vs those that are 'left in the plant.' A major part of those electronics that are not shipped in an IDE are those that relate to the ability to re-do the 'low-level-format' of the drive "in the field." Some *Will*Not* permit this to even be attempted. Other IDE drives that do allow it, suffer from various aspects of not having the electronics that are back at the plant present. I have heard reports that from folks that I generally trust to be correct that some IDE drives loose their bad.sector info and that others loose capacity, when they are 'field reformatted.' This is just not acceptable to me. This is why I've SCSI drives in all systems now. As to speed issues, SCSI-II, to quote from the Maxtor MXT-540SL data sheet (just got one a couple of weeks ago), Sync data transfers to the bus are up to 10mb/s and from buffer to disk, 40 mbits[sic][yes.its.bits]/sec. For command overhead, they quote </= 300 usec. Further, as I recall the SCSI-II spec, negotiation to SCSI-I is a required feature, so there should not be (and indeed I have not had any) with older design controllers. Back to 'cost issues' for a moment. The major cost element of a drive is the stuff that goes into the sealed disk enviornment. That is just a lot of nasty high precision machine work and coating technology in there... as well as the overhead of the clean.rooms for assembly of that aspect of the drives. This brings us back to the issue of the electronics that I spoke to above. I doubt that there is any material difference in the mechanical assemblies between SCSI and IDE... if any. Now, to FreeBSD/BSD-386 issues. In that so much code has been shared in these efforts, I expect that my experience with FreeBSD 1.1.5.1 is true for the other efforts as well. FreeBSD probes the hardware and takes note of MFM, RLL, IDE drives that are present but NOT set up in the cmos of the system. As a practical item, this allows installation of a 'dos' transfer filesystem on an st-506 drive. To boot from that drive, I have its specs saved in the user.definable locations in the BSD machine's cmos. When I need to boot to 'dos' (actually, Novell Dos 7), its a quit pass at the setup utility to step back one step to that entry, a save of the change and exit. I *HATE* to sit and watch for prompts to enter things at to get to the other OS... an 'old habit' from going for me.cup.o.java while the Cp/m system booted and loaded its M-disk and such. In summary, the major issues for me in my selection of SCSI are 1./ recovery of capaicity in a drive that has recieved a lot of intense use and that has re-mapped a lot of sectors because of sectors drifting to far into a gap (and proabaly trashing the header/tail info of the sectors around it) and 2./ the flexibilty of the bus itself. One example of this last item is a project in my 'wanta.que' using some 8.bit Emulex cards that I have full docs on for a SCSI-Net between two machines. The idea is to use one system as a 'port.server' for the other, thus getting past the bloody.lack.of.Interupts in the 'pc-bus.' Oh, do I miss the vectored sturcture of S-100. Good.Grief. As I said that, this beard turn pure.white and grew six inches. Time to go shave. ........................................................... Alan Ogden, Moderator of 'nos' on BIX arog@BIX.com