If the mobo is good, and the ide cable to the drive and the power to the drive are good as well, the drive is probably toast. Get the drive maker's utility to test it properly. Then you'll know for sure.

 

Okay - I am an *****. I should have thought of that myself - duh! I guess after trying to find any info on my mobo from its manufacturer (trying to find out who the manufacturer is, for that matter) I assumed that it would be another frustrating waste of effort - but I should have at least tried. The diagnostic they have should do the trick. Thanks for pointing out the obvious so nicely!

 

I don't think you're an *****. When I post, I try to give some help from what I have seen or heard, and it's merely my suggestion, not word from the mountain. You might have used a drive makers utility and said so and I missed it, rendering me an *****!
By the way, the drive was at the end of the ide cable when it was set as master right? If it's a master it should be at the end of the cable. Conversely, a slave drive should be in the first position. If you have the drive set as cable select, it can go anywhere, and bios for that drive should be set to auto.
When there's intermittent probs, I would see if there's a firmware update so you can basicaly flash another "bios" into the drive, in case it's a corrupt firmware issue.

 

I'm pretty sure it was in the first position since it was the only one I was trying to connect. But I thought that the master/slave jumpers would override the cable position. I try not to use the cable select jumper option on any hardware because that's been an issue before with some devices, and I thought that always using the right jumper settings would avoid that. If it still makes a difference even when using master/slave jumper settings, maybe that was part of the problem. I should remember that you can't count anything out when trying to figure out hardware problems, right?

Thanks again for being so helpful! FYI, the diagnostic program that I got from Western Digital's web site worked beautifully - found errors and repaired them without screwing up any existing data. In fact, I thought their tech support page was extremely well done and informative, and easy to navigate, and I can recommend it as a good resource for help.

 

Cool you resolved this. By the way, with sata drives there's no longer any master/slave, they are all "masters".

 

?? what's sata?

 

Serial Advanced Technology Attachment. It's a "new" standard for hard drive cableing and signaling. The cables are thin, about half an inch wide, and only have two connectors, one on each end. No more jumpers to set either. See, standard (paralell, the wide 40 and 80 wire cables) ATA drives such as the one you had problems with use a paralell interface hence the wide cable. It sends more data in paralell at a slower rate, rather than small amounts of data serialy at a much faster rate like sata does. To go any faster standard paralell ata has pretty much run out of speed, as to get wider data paths like ata to run faster you have to increase its signaling speed, and when the interface is paralell, thats much harder to do than when the interface is serial. You're talking 40 wires talking at a certain rate rather than two wires at that rate. Hard to keep the data from being received at unequal speeds on all those wires. This is called "group delay." There isn't much of a performance boost yet with sata, but when drives run at 10k rpm or faster, or sata raid arrays become more common, the need for sata might be realised.
Here's what the stuff looks like:

http://www.directron.com/patasata.html#hcp

Eventualy ata stuff will go the way of floppy drives and comm ports. Even optical drives are being made sata, and I have used sata adapters on optical drives with no problems, and some performance gain. Also, moreso than the sata interface, scsi commands are slowly being added to the sata command set. This might give sata drives more of a performance boost than higher spin rates and areal density. Look into the scsi command set to see the diffs between scsi and ide, wich is a primitive subset of the scsi command set.

PS most sata drives today are just ata drives with a sata adapter grafted on, they aren't true sata, with few sata drives being exceptions. Think the wd raptor is a true sata drive tho.
Thus endeth the sermon.

 

Wow. Thanks! I even understood most of that until you mentioned SCSI - for some reason I have never had any SCSI devices so it's unfamiliar ground for me.

If you don't mind a little more preaching, I'm ready to listen if you can tell me more. I've been out of touch w/ technology for a while and am way behind on some of this stuff :blush:. For one thing, if it was too slow and bulky, why not just replace the IDE interface with hi-speed USB or Firewire? I thought that those were supposed to have been the hot new connectivity item or whatever it's called, bigger, stronger, faster, all that and on-the-fly connecting, too. At least, I thought it was the last time I was in the loop. (I told you it's been a while!) I had the idea that everything was going to go USB/plug n play eventually. And it's being used for external HD's, flash memory, etc. now, so why bring this into the mix? Or is USB being phased out already, too?

 

USB hmmmm. As you might know, usb 2.0 is out, and on most recent mobos.
It's (usb) a great way to attach peripherals including the usb hard (non solid state) drives, but the driver layer is relatively huge, and sometimes its performance is spotty, all reasons why usb isn't used as a main system bus like pci or even isa. Latency is also an issue, usb is probably a good bit slower, latency wise, than the pci bus, to wich all onboard ide attachments access a system through. The pci and other transport protocols like hypertransport and v-link are better suited, and probably less complex than usb is, so they get more use.

Now, as to the "future" I suspect that someday the entire system bus will be "light", as in the electro magnetic radiation we use to see. The light bus would use different frequencies of light to connect different parts to their mate, or the mobo. Think fibre optic cable. The bandwidth of a light bus is pretty high, and latency should be pretty low. Guess cpus and hard drives will be a while before they can clog a light bus.
I suspect that all devices will use the same connector, and the differences in their communication speeds will be differentiated by the frequency of light they use, and this frequency would not have to be static, it could change as needed to support different communication needs.
Just some ideas.

 

a brief history of SCSI

SCSI: Small Computer Systems Interface. Three flavors, SCSI-I,-II,-III.
Expensive cables and hardware as there's lots going on.

Prior generation Macintosh systems were strictly SCSI. Professional Unix mid-range
Unix systems are SCSI. The original hardware included 7 id's, the controller was
always ID-7, the internal HD as ID-0, and others id's 1-6. Latter developments
expanded the channel to 256 Logical Units(lun). SCSI volumes always have
a volumn label which shows up as the device name. Mac and Unix systems
don't use drive letters (thank God!) so devices and access is more immune from
the configuration {Windows and IBM VM/CMS are the only systems I know that use drive letters}.

With an I/O channel of 6 drives, it was important to be able to transfer data
in parallel from multiple devices concurrently, and this support was available
from day one. When RAID arrive, it was first implemented on SCSI.

The USB 2.0 is the default I/O transport today. Firewire IEEE 1394 is faster,
but needs more expensive cables.

 

I love scsi.
The low cpu usage, the ability to attach just about any type of peripheral (making the scsi bus a REAL bus, oh but wait, there's a new scsi bus coming out too...), the speed of the latest drives (15k rpm, no ide drive can touch these), and the coolness factor of it all. Great for high cpu usage servers, and for responsiveness in a desktop environment when you are loading a system down with video encoding or similar apps. Scsi runs fine in areas where ide chokes. The real benefit of ide is cost anyway. Not that ide drives can't be fast.
The bad part is all scsi devices must have a singular id, and the termination of each cable is required as well. Id and termination/cable problems comprise probably over 90% of all scsi errors. And you didn't like to mess with jumpers? Scsi is all about the jumper! I set up a raid array with 20 some odd sca (these are scsi drives with the Single Connector Attachment config) drives in a raid box. I had to id all of them, and overlooked the fact that the controller by convention uses id7. Even the controller must have an id. If the controller is set to 7, nothing else better have 7 as id. So I wondered why the drive with id7 was hanging up...... Duh!!! Here I have had years of messing with scsi and forgot that little rule. Funny how one falls apart after about 36... The last scsi stuff I plan on messing with is a raid0 for my gameserver, got the hba (host bus adapter, the scsi controller card so you know) with 128m cache and dual channels ready for some fast map loading online fun! Just gatta get some nice 10k rpm drives is all.

Ok cost is a major factor in scsi too.

 

I'm catching up quickly - thanks guys :grinthumb

SCSI and SATA attach to newer mobos directly, right? I haven't seen a mobo with onboard SCSI (much less SATA) but as I said, I've been out of things for about six years. I'm assuming that they exist and as such, would have the advantages you've mentioned. What about SCSI adapters on older boards (like mine)? I've certainly seen them, and if I'm understanding things correctly, an adapter would still have to go through the PCI/ISA interface. Doesn't that kind of defeat the purpose of having a faster SCSI device, or have I gotten mixed up somewhere?

(thanks again for bearing with me!)

 

SCSI is almost always an OEM PCI adaptor like
'Adaptec AHA-2940 PCI-to-Fast SCSI host adapters provide a powerful multi-tasking...'

The install will update the BIOS to see the card.

UNLESS you have a specific need, don't go there, but rather stick with USB or Firewire.

 

"I've certainly seen them, and if I'm understanding things correctly, an adapter would still have to go through the PCI/ISA interface. Doesn't that kind of defeat the purpose of having a faster SCSI device, or have I gotten mixed up somewhere?"

Yes, adapter cards use the interface they are connected to to access the system, and hence the bus' limitations apply. So if the 32bit/33MHz pci bus is 133mb per sec in theory, you can't go beyond that transfer rate. With raid you can fill it to max tho. Without raid you will probably never clog a pci bus. There's also the lower cpu usage of real scsi controllers to consider, they have their own cpu to handle the math used for ecc and so on, and to access system memory. The scsi card I am going to run in my game server is an lsi 1500, it has it's own cpu (Intel i960... ooooo) and 128megs ecc sdram. It may be an older card and not have the transfer rate of the latest stuff, but I could care less, it's (scsi) being used for the lower access times of 10k rpm scsi drives and the cache onboard. Once data (both read and write) hits the cache it can be accessed almost as fast as system memory, latency wise. Data written to cache to be written to the drive can be written as the drive has time, greatly increasing apparent speed as other wise the drive would have to write the data immediately, interrupting anything else that needed disk attention. Think of system memory access as equal to an email. Think of non-cached drive access as sending the same message by a freighter ship, taking months to get there. This is how the cpu views things.
128megs cache gives more data the opportunity to be cached over a lesser amount of cache.

All of the techniques described as pertaining to scsi are going to be added to sata eventualy, and there's a lot I haven't covered, such as command queueing and so on. Google for that stuff.

 

Thanks again, guys, for the informative lessons, and your patience with my in-training questions. I can now venture forth with a much better understanding of different drive interfaces, and if I feel the need for more details I 'll Google as suggested.

Things have sure come a long way from the days when you sat down at a PC with nothing but a keyboard, two floppy disks, and a C: prompt!

 

Yeah they have come a long looooong way.
In summation, I should also say that if the drive that was giving you problems ran fine for a length of time prior, I would be suspicious of it as something, probably electronic or firmware wise, must have changed to make it fail. If it runs fine now, great, but be taking a closer look at it, operation wise, from now on.

Any more questions we will be glad to answer, just make sure to post them rather than pm them so others can correct my mistakes! If you do post a question for me and I don't see it, pm me to it and I'll be sure to repond.