Slashdot Mirror
Western Digital Pulling Out Of SCSI HD Business
leiz writes "This article on Yahoo says Western Digital is pulling out of the enterprise hard drive business. This means they will no longer produce SCSI hard drives and Western Digital will be instead concentrating on the IDE and software business. What does this mean for the SCSI market? With 7200 rpm UltraATA/66 hard drives catching up in performance to SCSI HD, products such as the Fastrak RAID 0, 1, 0+1 card, and the cheap cost affectiveness of IDE/ATA, is SCSI no longer necessary for desktops / workstations / small servers?"
The current implementation of SCSI is 160 Mb/Sec. SCSI is a multitasking i/o subsystem (simultaneous read/write), IDE is not. SCSI typically impedes CPU performance by 3%, while IDE typically impedes CPU performance by ~25%. For Starters.
Come see Mr T teach CmdrTaco a lesson!
I pity the fool who don't like mr T!
Mr T vs Slashdot
Go Read it suckas!
I spent seven years at Western Digital, and I watched a chip company with an amazing amount of IP (basically everything except processor and memory) scuttle the chip business on the alter of the almighty hard drive. WD has seeded many successful companies in SoCal (Broadcom, QLogic, Emulex, Silicon Systems, Adaptec, JNI, more...) by letting go their talented engineers when management had failed yet again to follow in a market where they should have been leading. I'm sorry to have seen it happen yet again. Sounds like sour grapes, but it's really not; I'm just not surprised at this latest news. It's just another round of layoffs at WD, which isn't really anything new there. To any of the old guard still there -- you're a hardened lot, and I wish you luck in yet ANOTHER new direction set by the company. As for me, let's just say that in retrospect, WD was a great place to be from.
You don't use science to show that you're right, you use science to become right.
I've found the IDE performance problems go away entirely with the correct bus-mastering settings. You still can't get decent performance with two drives on a single channel, but my new Abit motherboard came with four IDE channels. So you can have four IDE hard drives without losing performance.
Here are some real benchmarks to back this up:
[root@olympus /root]# /sbin/hdparm -c0 -d0 -k1 -m0 -W0 /dev/hda /root]# /sbin/hdparm -t /dev/hda
/dev/hda: /root]# /sbin/hdparm -c1 -d1 -k1 -m16 -W1 /dev/hda /root]# /sbin/hdparm -t /dev/hda
/dev/hda:
<snip>
[root@olympus
Timing buffered disk reads: 64 MB in 28.40
seconds = 2.25 MB/sec
[root@olympus
<snip>
[root@olympus
Timing buffered disk reads: 64 MB in 4.86
seconds =13.17 MB/sec
That's with a 7200 Seagate drive. The first benchmark, giving a whopping 2.25MB/sec, was with all the IDE options in sucky mode. This is the way older IDE controllers work, and in large part responsible for IDE's bad name. The second benchmark shows that it can have good performance. It's CPU performance wasn't as good as SCSI's (17% out of 200%; dual-processor box) but wasn't as bad as many have said.
The big trouble with IDE is still that they are "dumb" devices that require CPU resources to manage. On workstations doing lots of disk access I can see NOTICABLE performance degradation between similar hardware, one of which is IDE, the other of which is SCSI. The nicest thing about SCSI is the fact that the controller offloads all disk management off of the system's CPU. If you're doing power computing, this makes a big difference. Also, as someone else mentioned, IDE has real problems allowing the system to manipulate multiple drives simultaneously, a problem SCSI does not have. For some schmuck just dicking around with Netscape so they can browse the web, who cares, but for hardcore users with big machines trying to get real work done, it can make a legitimate difference.
From a server perspective, there's no question that SCSI is the best. Just TRY putting more than four IDE drives into a Linux box without tearing your hair out and threatening to take a shotgun to the thing. The only way to do it is to get some sort of additional IDE controller like the Promise controllers which are unmitigated junk. I don't even want to mention the hoops I've gone through to to get a Promise Ultra33 stable in my Linux server. What makes it worse is that I could buy the four IDE drives I put in there for about the same price as I would have been able to pick up two SCSI drives of about the same size. (It's not that SCSI is so tremendously expensive as much as it is that IDE is just dirt cheap.) More unfortunately, I needed the space and I didn't have the extra money, or I *would* have just gone with SCSI. (As it turns out, I spent so much time trying to get the IDE drives working, I probably *should* have just gone SCSI from the get-go and saved myself money in the long run from doctor's bills from high blood pressure and ulcers trying to build an IDE-based server will give me.)
I see the whole "IDE vs. SCSI" thing as yet another case of mediocrity winning the battle. It doesn't have to be great as long as it's cheap and good enough to get the public to buy it. For those of us who like quality, we just have to pay so much more. Unfortunately, unlike the software industry, there's no way to start an "Open Source/Free Hardware" movement to force the other manufacturers to start focusing higher on quality.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
I've got to say, this doesn't suprise me one bit.
I worked for a Computer Repair shop for about 5 months now. Here's the Breakdown on the Brand Names of Drives that come in Crashed that I've seen so far.
90% Western Digital - at least 20 that I can think of offhand
8% JTS (which are out of business) - 2 of these
2% Seagate - I know of 1 that had bad sectors
As of yet I've seen no Maxtor, Fujitsu, IBM, Quantum, Samsung or any other manufacture's hard drive crash. Although I've heard alot of bad things about the Maxtor Drives and the Quantum Bigfoot's Crashing. and I know from personal Experience that some old IBM Drives, (and I'm talking 10-15 year old PS/2 Hard Drives) were crap.
We would sometimes get WD drives that came fresh out of a box, stick it in a machine, and it would be damaged. My boss Had to deal with a company for a week because They bought a WD Enterprise Drive for their mission critial Server and it crashed. It Wasn't even a year old!
If I had a choice of any drive today, Hands Down I would have to go with the IBM Drive. If I had a second choice, I would probably go with a Samsung or a fujitsu.
In Soviet Russia, Trojan exploits YOU!
EIDE will eventually hit limits as even desktop computers become more demanding. As that time arrives SCSI will take over. On the server front, fibre channel is looking like the future over SCSI. It may be even more expensive but it is faster, has a crazy 10 km or so distance limit, supports more devices on one loop, and supports multiple HBA's connected to one set of devices. This allows multiple systems to talk directly to the storage rather than through a network to a computer that talks to the storage. SANs are going to really need fibre channel.
SCSI may seem to be "too much" for the average user but in that as the old MTV logo used to say..."Too much is never enough!" This held true for music television and it holds true for computers. I remember getting time on a 386 SX 25 Mhz with 4MB RAM and 80 MB hard disk. This was a $10,000+ system at the time. Now it's a paper weight for all but a few geeks (like me) who love to find uses for old hardware. I have a few IDE paper weights...I will have a few more before they are done.
-- soldack
Face it, the IDE design is ancient and is inadequate for today's uses. I mean its fine when you are plain ol' Joe Bob who just checks his email and does word processing. But when you want to *add* something to the computer and do some serious stuff, like a geek will, you're running into problems.
Not only does IDE have bad command queuing, it doesn't even do sync transfers. The most debated issue is the CPU usage and the transfer rate: IDE relies on the CPU more than it should because the controller is too simple and therefore braindead. You can overclock the IDE controller, but what always happens is the drive is too crappy to even handle the higher speed, but you always get the same read performance. IDE always sends date from devices back to the host controller at the same original spec speed, whereas write-to-device can vary due to oc'ing the controller.
Ok, now to the point:
the engineers (I'm sure they've been TOLD to do this) keep trying to make IDE "better" by keeping this backwards compatiblity junk and at the same time trying to squeeze a wider data bandwidth for the devices. Think about ATA/66, you need those special 80 wire/40 pin cables because if you used a regular 40 pin/wire cable the signal to noise ratio will be so bad that you get tons of CRC errors. The additional wiring are for the extra shielding in order to keep the SNR well enough to avoid CRC problems. What about adding additional devices for more storage space and removable like what most of us geeks do? Okay, they draw up these brilliant schemes of secondary, tertiary, and quarternary controllers which are essentially the same in controller design as the "primary" except on a different IRQ and port. Wow, cool, now I can hook up 8 IDE devices!
Ok, but I want to add some stuff like: a PCI soundcard (2 IRQs... 1 for ISA/DOS emu, and 1 for actual PCI), add NIC (there goes another IRQ), add DVD decoder card (1 IRQ). Hmmm... wait a minute, isn't IDE 0-3 using IRQ 10,11,14,15 already? So didn't that left me with IRQ 9 for video? Ok, suppose I _DON'T_ even have a NVidia based video card (which has problems sharing IRQs), and try to share IRQ 9 through "PCI steering" with the USB, also; that only gets me 2 devices working. I still have to disable the serial port(s), and the parallel port to get more of this working. It is possible to have one of the devices' IRQs share with the other, however this is all determined by the BIOS's DMI these days (in a modern PCI BIOS at least). I'm only talking about PCI here, ISA is already a forgotten issue since I'm talking about the latest and "greatest" motherboard.
Aren't they trying to keep some ancient inferior, simple interface up to date and competitive just because its "cheaper"? AFAIK, it should cost no more to make a SCSI device/drive with the *same* MTBF rating as an IDE device. IDE works, only when you are keeping things *simple*, but things aren't so simple these days. The more expensive, branded, prebuilt *gasp* systems these days already come with a decent sized HD, with DVD, and usually a burner, and sometimes a Zip or LS-120. This means 2 IDE channels may already taken up. IDE seems cost effective, but it doesn't look like it to me when it comes to long term. Its more trouble than its worth when you are going to add cards into your slots. Doesn't this remind you of the saying "beating a dead horse" to you?
It all comes down to this: we all know that we are in a serious IRQ resource problem already, and adding to that we get "newer and better" IDE "standards" which contributes to this problem even more. What I think should be done is to either ditch IDE (it worked great as a cheap solution but is no longer really viable), or take care of the IRQ problem. However, there is one thing that seem to be preventing this: the industry thinks they need to maintain backwards compatibility. I feel that there will eventually come a day where someone out there in some company will crack and actually officially acknowledge of this problem and is actually willing to deal with it.
My strongly suggested action is to actually make SCSI cheaper (man, they make tons of money selling those things, when costs of manf are no more than IDE), thus allowing IDE to be rid of, and in turn allow us to connect at least 15 devices (Wide SCSI) and using only 1 controller, 1 IRQ, 1 port, and lower CPU usage tremendously.
I still have to admit that IDE is ideal for people, and some of the geeks out there who are poor and can't afford good stuff like SCSI. But the minute you can afford and want to do serious (workstation/server) stuff, there is no doubt about it: SCSI is the way to go.
TheMAN
Here's a tip sent around our company concering tweaking IDE perf. Thanks to Andrew Tridgell for the info.
/dev/hda /dev/hdc
/dev/hda /dev/hdc /dev/hdc > /dev/null & /dev/hda /dev/hda /dev/hdc /dev/hda
This tip is useful for just about any Linux box, and is probably the
simplest way to significantly speed up your IDE based Linux box
without changing the hardware.
If you are impatient then just add the following near the top of your
/etc/rc.d/rc.sysinit (or equivalent startup script):
/sbin/hdparm -u 1 -d 1
/sbin/hdparm -u 1 -d 1
(and so on for any IDE devices in your system)
Now for a more complete explanation.
By default Linux uses extremely conservative settings for IDE. In
particular the default settings do two things that make IDE perform
really badly:
1) DMA is not used. That means all data coming to/from the hard disk
or cdrom is processed a byte at a time by the CPU. That is not very
efficient. With a fast processor that isn't doing anything else at
the time this can appear fast in simple minded benchmarks but it is
a big drain on CPU resources when you are actively using the
machine.
2) hardware interrupts are masked during IDE transfers. That means
that while a lump of data is being transferred to/from a IDE device
no other interrupts are processed. This includes interrupts from
other IDE devices, from network devices, from serial ports and from
mice. Your whole machine is effectively clagged up doing nothing
but waiting for a horrendously slow device to say "I'm done". Not
good.
If you want to see just how slow this is on your system then do the
following:
1) put a CDROM in the drive.
2) run the following commands:
hdparm -d 0 -u 0
hdparm -d 0 -u 0
cat
hdparm -t
hdparm -d 1 -u 1
hdparm -d 1 -u 1
hdparm -t
that shows you the hard disk speed while accessing the CDROM with the
default settings and with the improved settings. On my system the hard
disk speed goes from 3.8 MB/sec to 12.9 MB/sec. I've seen much bigger
changes on some other systems.
Even more importantly than the speedups is the fact that you will stop
dropping your PPP connection while doing cdrom transfers, and you will
be able to use your system while burning a cdrom without creating a
coaster.
You may wonder why the default settings are so poor. The reason is
that there is some rare hardware out there that corrupts data during
IDE transfers when you either use DMA or receive an interrupt during a
transfer. If that happens then the kernel should detect the failure
(in nearly every case) and fall back to the default
settings. Unfortunately after the auto-fallback you are still left
with corrupt data in your cache. Luckily systems that don't handle DMA
and unmasked interrupts are really quite rare these days so it is a
pretty safe bet to turn the options I suggested above, especially if
your system isn't from the stone age.
For more info and piles of options for fine tuning your IDE system try
"man hdparm".