Hard Drive Performance - ATA100 vs ATA133

Tweaker writes "A short visual guide to the performance advantages of ATA133 over ATA100. Synthetic and real-world benchmarks are also included."

Comments

There's no comparison

[ObviousGuy]

They are pretty much the same. :-/

Perhaps it is simple a case of the technology being too young to actually realize the 33% expected increase in performance, but the numbers just don't add up.

Bottom line: Save your money, don't go rush out and buy the boards or the drives.

Re:There's no comparison

[trolliamnot]

YOu are pretty much an idiot. :-/

Perhaps it is simple a case of you being an idiot.

Bottom line: You are an idiot

Re:There's no comparison

[Elbereth]

They should do a comparison between ATA/33 and ATA/133. They might possibly find a difference there, but I sort of doubt it, unless they're using high end drives.

This is why servers use SCSI hardware, not EIDE.

Re:There's no comparison

[ObviousGuy]

Thanks for the info!

Re:There's no comparison

[flatrock]

Servers use SCSI because it's more expandable, and better RAID solutions are available. It's also true that the highest end drives are SCSI, but this is more of a case where they can demand a higher price point for SCSI drives, so SCSI is the only type of drive where it's profitable to market those high end drives. The same higher density, faster spindle drive technology will eventually reach the IDE market, and will perform in a comparable fasion there. SCSI also has the advantage of being able to reorder requests so that it can access the data sequentially. There are some applications where this can be taken advantage of if the drives and HBA support it, but in general, the effect is minimal.

Re:There's no comparison

[Cramer]

Servers use SCSI because they need to be able to queue multiple commands to the drive (read: multi-user environment.) Add to that the quality and lifespan of your agerage SCSI drive, and the price is well worth it.

Sitting right here with my dual PIII-800 IDE (ATA100) feed W2k box, IDE works just fine as long as there's only one thing playing with the disk. When the index engine fires up, the box is no longer usable. (It's actually very annoying.) On the dual PII-450 SCSI (U2) feed W2k box, I cannot tell when the indexer is running.

Re:There's no comparison

[trolliamnot]

Are you coming on to me?

Re:There's no comparison

[VB]

"... lifespan of your agerage SCSI drive ..."

Any ideas what this lifespan is? What about for (E)IDE drives?

I've got 2 - 3 GB drives still working after 8 yrs full-time use. I've had more IDE drives (IBM, Western Digital) die in the past 2 years that were purchased w/in the last 4 years than I can count.

The drives keep getting bigger, and for those of us who only want 10GB to run a server, it seems like a good idea to steer clear of 250 TB IBM EIDE drives at Fry's, especially when they're not recommended for fulltime use. I'd imagine other people have made this observation.

Re:There's no comparison

[kill-1]

That would be interesting, because I just bought a Western Digital 1200JB for our small office file server with an old ASUS P2B-DS motherboard supporting only ATA/33. 'hdparm -t' shows only a little over 20MB/s, which seems slow for that drive. OTOH 100MBit ethernet is still the bottleneck, so I'm fine with it.

Re:There's no comparison

[drsmithy]

They are pretty much the same. :-/

Of course they are. The bottleneck in hard disk speed is not the interface (unless you've got a honkin' great big SCSI RAID). You could do the same comparison with those drives on an ATA66 controller and the difference in speeds would still be negligible. Even the fastest IDE drives are only pulling about 50MB/sec - it should be obvious that raising the speed of the controller when the physical media is the bottleneck isn't going to give a significant improvement.

Perhaps it is simple a case of the technology being too young to actually realize the 33% expected increase in performance, but the numbers just don't add up.

The numbers do add up. It's simply a matter of looking at where the bottleneck is. You'd get similar results from a single drive and 80, 160 and 320MB/s SCSI controllers as well.

Bottom line: Save your money, don't go rush out and buy the boards or the drives.

Bingo. I'm not sure of the people writing comparisons like this are ignorant, stupid or simply trying to deceive their readers (kickbacks from the hard disk dealers maybe ?). Of *course* there isn't going to be a performance increase from a faster controller when the controller isn't the bottleneck. Just like you wouldn't get a big speed improvement in the latest gee-whiz 3d shooter by replacing the Riva128 in your P200 with a GeForce4.

Re:There's no comparison

[nil_null]

They should do a comparison between ATA/33 and ATA/133. They might possibly find a difference there, but I sort of doubt it, unless they're using high end drives.

There is definitely a difference. I was using my onboard ATA33 controller with an ATA66 (Maxtor DiamondMax) and an ATA100 drive (Seagate Barracuda IV). I recently bought a SIIG ATA133 controller I found on sale. According to SiSoft Sandra's benchmarks, there was an 85% increase in performance for the ATA66 and a 70% increase for the ATA100. Granted SiSoft's drive benchmarks aren't really precise, but nevertheless the improvements were pretty significant.

Re:There's no comparison

[Cramer]

Quick answer: at least as long as the manufacturer's warranty.

Most modern IDE drives aren't rated for continuous use. They tend to last one or two years before they begin to show mechanical failure (drive bearing fail.) The IDE drives of old are pretty tough creatures as long as they don't experience any shock during operation.

As I've said many times, I've never (in 20 years) had a SCSI drive fail right out of the box. I've had numerous IDE drives not work right out of the box (and even RMA replaced drives show up broken.) And when you've seen how manufacturers determine MTBF, you stop looking at those worthless numbers.

Re:There's no comparison

[spunkykuma]

It's not necesarily the lifespan itself, but the durability is more important. I've found SCSI to be far better built than IDEs and can last longer, I've kicked a couple Seagates around by accident during operation, dropped some others, and they still work after years of non-stop operation. I've had some IDEs die for no reason, some early Western Digitals were known to die on a PC power up after being in operation for a long period of time without the PC being powered down.

Re:There's no comparison

[ez76]

Servers use SCSI because they need to be able to queue multiple commands to the drive (read: multi-user environment.) Add to that the quality and lifespan of your agerage SCSI drive, and the price is well worth it.

This is disingenuous, depending on your definition of the "average" SCSI drive. The majority of SCSI drives that spin at less than 10k rpm are using the same hardware as their IDE counterparts with different controller hardware.

No shock

[supercytro]

It comes as little surprise that there is negliible performance difference between ATA100 and ATA133. The nomenclature seems to imply superiority i.e. it's 33% better! but is no more credible than Intel 's advertising push of MHz as a comparator. There is an interesting line in the conclusionn tho, which says "Keep that main idea behind ATA133 is minimise bottlenecks in the system when your running MORE than one drive, and to allow manufacturers to build drives larger than 120GB" but even this advantage isn't generally realised.

Re:No shock

[mccalli]

"...to allow manufacturers to build drives larger than 120GB" but even this advantage isn't generally realised.

Yet.

Wasn't long ago that 40Gig was considered special, now 120Gigs are kicking about and I imagine it won't be all that long before the 120Gig drives are being called 'low end' either.

Cheers,
Ian

Bottleneck must be elsewhere

[digital_freedom]

For the ATA133 not to beat the ATA 100 must mean that the systems stested have their processing bottleneck elsewhere. Maybe it's the RAM bandwidth or one of the bus bridges. I would've liked to see this test done with some different motherboard chipsets to see if different architectures make more sense.

Re:Bottleneck must be elsewhere

[Wonda]

sure there is a bottleneck it's the HDD speed, it isn't even close to saturating ATA100, in fact ATA66 would be enough.

Re:Bottleneck must be elsewhere

[Anonymous Coward]

You think memory bandwidth is going to be a bottleneck over hard drive speed? EARTH TO RETARD: hard drives can't come close to filling the bandwidth available to them by modern controllers. Hell, you'll see the same speeds on an ATA66 controller if a drive is only going to put out 37 MB/s to begin with. Gimme a break.

Re:Bottleneck must be elsewhere

[KingKire64]

...Or maybe the hardDrives arent fast enough to take advantage of the speed. The whole thing with ATA 66+ is that the drives are only as good as the burst speeds becuase the average speed on the drive doesnt even take advantage of ATA 33

Re:Bottleneck must be elsewhere

[Znork]

No, the bottleneck is the same as it's been the last 5-10 years. You cant get better performance reading and writing to disk as long as you dont have better performance between the platter and the head of the drive. You can get a ATA500 bus and it wont make any difference as long as you cant read faster off the disk. You have to get faster disks (try a 15k rpm disk for example).

For SCSI the bus speed can make more of a difference since you can have more devices per bus. But with IDE's pitiful 2 devices the bus doesnt really make a difference for any OS that has a memory FS cache already (which will usually sequence reads and writes enough that the disks own buffer doesnt matter much (which is the only thing you're getting more speed against with a faster bus)).

Re:Bottleneck must be elsewhere

[Zathrus]

No, the bottleneck is the drives.

The fastest IDE on the market is still only spinning at 7200 rpm. Maximum transfer rate is going to vary depending on the media density at the outermost track on the drive, but in general it's still not going to approach 133 MB/s. Most IDE drives have sustained data transfer rates in the 50 MB/s range (the Maxtor D740X, which is one of the most popular IDE drives on the market currently, has a sustained transfer rate of only 44.4 MB/s at the outer diameter and 24.2 at the inner, as per Maxtor's own tech sheet).

If you read the literature from Maxtor, who designed this standard, even they will admit that the maximum transfer rate will only occur on a read from cache - and the biggest cache on an IDE drive is a whopping 8 MB. So congrats on sustaining that maximum transfer rate for all of 60 ms. After that you're back to reading from disk.

The only real advantage of ATA133 is to support drives >120GB. Of course, the funny thing is that the only 160GB drive available right now is a mere 5400 RPM (with a lovely 35.9 MB/s at outer diameter).

ATA133 is widely regarded as a marketing gimick. Apparantly it's working though, since some people actually think it matters.

Re:Bottleneck must be elsewhere

[Anonymous Coward]

Yeah OR the winxperated DMA driver for the 133 controller sucks.

Re:Bottleneck must be elsewhere

[EmbeddedHead]

If your running windows (NT or 2k), the bottle neck is the OS.
The NT microkernel was designed serialize all IDE device access in the drivers.
Therefore, if multiple processes are attempting concurrent IDE subsystem access, each data transfer request will run to completion.

It actually makes no difference if the processes are attempting access to different physical devices, because it is the NT driver layer that enforces this restriction.
This is especially bad for an OS that relies on a page/swap file residing on a shared resource.

Only viable solution for concurrent access: use only SCSI devices.

Re:Bottleneck must be elsewhere

[13Echo]

Great post. Where were you about 3 months ago when my friend swore up and down that his ATA133s were going to smoke my ATA100 drives? I tried to convince him to get a better drive, but he insisted on an ATA133. Maxtor makes good quality drives, but there are still plenty of faster ATA 100 solutions at the same price.

It is all about tricking the idiots into spending more money for the "bleeding edge components".

Re:Bottleneck must be elsewhere

[IPFreely]

The only real advantage of ATA133 is to support drives >120GB.

Yes, that is the real advantage, and probably the reason that ATA133 will eventually become the standard for all drives/controllers. through the years, increasing capacity has always been a driving force behind changing standards. Increaced speed only matters if it is measurable.

Of course, the funny thing is that the only 160GB drive available right now is a mere 5400 RPM (with a lovely 35.9 MB/s at outer diameter).

Just because the only available drive is no good doesn't mean the standard is worthless. If you need the capacity, then ATA133 is worth it at any. Large drives are on the way, and the first step is the interface. If we weren't willing to change standards for larger drives, then we'd all have farms of hundreds of 120MB drives right now. It's worth it to change the standard to allow capacity even if there is not an immediate benefit of speed.

Apparantly it's working though, since some people actually think it matters.

Yes, we do.

Re:Bottleneck must be elsewhere

[Waffle Iron]

But with IDE's pitiful 2 devices the bus doesnt really make a difference

I prefer to think of it like this: IDE providees 1/2 bus per device, whereas SCSI only provides a pitiful 1/16 bus per device.

Re:Bottleneck must be elsewhere

[Anonymous Coward]

If you are going to be an idiot and spend lots of money, you could at least get 15K Ultra160 SCSI and legitimately smoke some ATA pleb drive.

But in general, you should be able to shut your friend up by pointing out that his computer != his dick (for example, his dick never sees the suck fest that is a 5400 rpm drive.)

Re:Bottleneck must be elsewhere

[Zathrus]

Never meant to imply the standard was worthless. Just that it has nothing to do with speed and everything to do with capacity. At least this time they extended addressing to a "more than reasonable" limit. It's doubtful that we'll exceed 2^48 addressing on a single drive in at least the next 3 or 4 years ;)

Re:Bottleneck must be elsewhere

[arkanes]

I'd imagine that drives with really big buffers, like the new western digital ones, will see a performance boost, especially in writing. At least as long as you keep your data nice and sequential.

Re:Bottleneck must be elsewhere

[AsylumWraith]

So your solution is to go back to an MFM bus, right? I mean, you can only have one drive on an MFM bus. So the device has the entire bus to itself... :p

Re:Bottleneck must be elsewhere

[Anonymous Coward]

If we weren't willing to change standards for larger drives, then we'd all have farms of hundreds of 120MB drives right now.

First, my '386 supported 528MB/drive, a far cry from the 120MB you cite. Bigger with a drive manager.

Second, just think of the parallelism in a 303 drive (303 * 528MB ~= 160GB) RAID0 array! You sure that farm of small drives is so bad? Of course, it'd take 21 Wide SCSI, or 152 IDE, channels to run them, and you're in trouble if one of them packs in, but let's not go cluttering this up with the facts!

Re:Bottleneck must be elsewhere

[cheezedawg]

The newer drives with larger caches (8 MB and bigger) can burst and fill the bandwidth of the controller.

Anyway, you might notice that none of the Intel chipsets support ATA133. Its not because Intel doesnt have the technology or that they are behind- they are just choosing to spend their time and money on SerialATA. Now thats a technology that actually has a future.

Re:Bottleneck must be elsewhere

[cheezedawg]

Yes, that is the real advantage, and probably the reason that ATA133 will eventually become the standard for all drives/controllers.

ATA133 will definatly NOT become the standard- parallel ATA is pretty much at the end of its road. The future standards will be with serial ATA. Where parallel ATA is reaching its limits at 133, serial ATA is planned to have speeds of 600 MB/sec within the next few years. Plus it is software compatible with the older conrollers (no new drivers), uses less power, and gets rid of those annoying ribbon cables that restrict airflow. All of the major chipset designers are moving on to serial ATA.

Re:Bottleneck must be elsewhere

[ncc74656]

If you read the literature from Maxtor, who designed this standard, even they will admit that the maximum transfer rate will only occur on a read from cache - and the biggest cache on an IDE drive is a whopping 8 MB. So congrats on sustaining that maximum transfer rate for all of 60 ms. After that you're back to reading from disk.

When you also factor in what types of apps would benefit most from a higher sustained transfer rate (video editing, for instance) and the sizes of the files involved (I have the most recent Enterprise on my hard drive right now as a 27GB Huffyuv-compressed AVI at 2/3 D1), the cache becomes even less relevant.

Re:Bottleneck must be elsewhere

[Anonymous Coward]

Oh, boy! It'll burst for a fraction of a second. Hold me back.

Perhaps you should consider looking at some of the comparisons of those Western Digital drives. The 8 meg cache version only outperforms the 2 meg version by a siginificant margin in ONE test that I saw listed. Some sort of Photoshop save if I remember right. In every other regard, the 8 meg version showed no appreciable advantage.

Re:Bottleneck must be elsewhere

[Anonymous Coward]

You'd imagine wrong. Go look at the benchmarks which compare the 2 and 8 meg versions. Also, remember that we're talking about 133 megs/sec. That extra 6 megs will be eaten up in about 1/22 of a second at that speed.

Re:Bottleneck must be elsewhere

[Anonymous Coward]

An 8 MB burst at 133 MB/sec lasts about 60 ms- 60 ms is an eternity when you are dealing with billions of cycles/second...

Re:Bottleneck must be elsewhere

[mczak]

> The only real advantage of ATA133 is to support drives >120GB.
Why does everybody believe this, even on /.? Someone (VIA, Maxtor ?) must have done a very good job of spreading misinformation. So, again: ATA133 (aka "Fast Drive") has nothing at all to do with LBA-48bit addressing (aka "Big Drive"). Nobody will stop you from implementing a bios with lba-48bit support for an old udma33 controller. Of course, you won't see any support for such old hardware, but today you are already able to use harddisks >128GB on a lot of boards with udma100 controllers. If you don't believe me, believe asus: how big hds are supported on asus boards (sorry the link is in german, but the table almost only contains numbers).

Re:Bottleneck must be elsewhere

[unitron]

MFM isn't a bus, it's a way of encoding the data for writing to the disk. It stands for modified frequency modulation.

Perhaps you're thinking of the pre-IDE system where the controller circuitry wasn't built onto the paddle board on the drive but was on a separate ( 8 bit) controller card that plugged into the ISA bus slot. This was done with both MFM and RLL (run length limited) drives, but even with this setup there was a 34 conductor data cable that could have 2 drives on it. The 20 conductor controller cable could only serve one drive, but there were plenty of controller cards that had 2 20 pin headers so that 2 drives could be connected to one card (and one IRQ, though I've forgotten which one ).

Hardly Revolutionary

[delta407]

Well, the tests show near-identical performance between ATA100 and ATA133, with ATA133 occasionally performing worse than ATA100. So, it could be just the test system, but, I'm going go to SCSI anyway.

Besides, hardware RAID is fun :-)

Re:Hardly Revolutionary

[flatrock]

It doesn't matter if you go with SCSI, IDE, Firewire, or FibreChannel. The limitation is still going to be the drive speed. SCSI drives (which include fibrechannel, and possibly Firewire) may have an advantage in that they can reorder requests to the disk to improve performance. In reality the benefit in most cases is negligable, and there's no requirement that the HBA or disk supported it.

SCSI gives you the ability to connect more disks both internally and externally. Firewire gives you the advantage of hot plugability and easy cabling. If you have a lot of disks, Firewire may not have enough bandwidth. Fibre Channel offers LOTs more disks, LOTs of bandwidth, Multiple protocols (IP and otheres), long cable lengths (10km). Of course you tend to pay more for more features. If you need the features, pay for them.

Re:Hardly Revolutionary

[Anonymous Coward]

Actually you are going to hit with an ATA133 limits even with SCSI.

Why ? PCI 33MHz/32-bit burst rate IS 132M Bytes/sec. Unless you have a PCI 66MHz / 64-bit or the newer PCI X buses and SCSI card.

ATA133

[Anonymous Coward]

Hey, cool comparison but I feel it overlooked the real reasons behind the move to ATA133.
ATA133 isn't special because it will make hard drives faster. It's special because it will keep the interface from being a limiting factor in your hard drive performance. That would be criminal.

IDE hard drives are pushing the 50mb/s mark. If one should place two of them on a channel and run intense I/O on both you can come fairly close to the 100mb/s barrier imposed by the interface. ATA133 obviously offers an additional 33mb/s of growing room for hard drive performance, which would be crucial for *future* hard drives. Why would a company spend money on R&D for creating a newer faster hard drive if it would not be able to perform any faster than what what's already on the market due to an interface limitation?
ATA133 aleviates another barrier of ATA100 that the IDE drive manufacturers have already begun to run into: The 120gb limit. There are currently 160gb IDE drives on the market, and if one should only have an ATA100 controller in their box they would be losing 40gb. That's no good at all.

I hope this is received ok. I'm not trying to be cynical or rude. I could just imagine somebody skimming the comparison and then deciding based upon it that they shouldn't worry about ATA133 being an included feature in a new motherboard purchase, which is a decision they may regret in the not too distant future.

Re:ATA133

[SkulkCU]

I could just imagine somebody skimming the comparison

Don't worry, /.'ers don't read the articles at all.

(btw, the short conclusion page of the article does mention the 120gb limit)

Re:ATA133

[Rolo Tomasi]

Uhm ... Ultra ATA 100 (ATAPI-6) already supports 48 bit addressing, thus allowing for 144 PB (that's petabytes) disks. Furthermore, it is inadvisable to connect more than one hard drive to one ATA channel, because of the crappy interface design (only one disk can transfer at a time, DMA problems). So this is nice marketing blurb, but in reality it's pointless. HDDs won't get past the 100 MB/s until at least 3 years from now, and by then Serial ATA will already be ubiquitous. Conclusion: if ATA133 comes with your mainboard, fine, but don't pay extra for it if you've already got ATA100.

Re:ATA133

[selectspec]

I agree. The interface is not the current bottleneck to drive performance. ATA133 is giving a little breathing room for future drives. However, drives have a long way to go. Even the fastest high end SCSI drives barely push 50MB/s (with write caches on). The big gain with ATA 133 is the increased logical address space.

Re:ATA133

[Zathrus]

Ok, after having done more research than I thought would be necessary...

Most "ATA/100" systems aren't implementing ATAPI-6. They're implementing ATAPI-5 with an extention that includes UltraDMA Mode 5. ATAPI-6 does have 48-bit addressing, and Maxtor has implemented an extention that adds UltraDMA Mode 6 (aka ATA/133).

Note that ATAPI-5 is the current official standard. ATAPI-6 is _not_ yet official. See the Technical Committee T13 website for details. Another good reference is ATA-ATAPI.com, along with PC Guide ATA standards.

The net effect here is don't confuse the physical interface (ATAPI) with the network interface (UltraDMA). Yes, nitpick at the terms, but that's what it boils down to. Your "ATA/100" motherboard does not support 48-bit addresing.

I agree, however, on the crappy design, the marketing blurbishness, the projection of HD speeds, and your recommendation about not running out and buying a 133 adaptor.

Re:ATA133

[Anonymous Coward]

What drive pushes 50 MB/s sustained?

Two drives on a single IDE channel does not equate to twice the bus utilitization. In many cases it just halves drive utilization.

The 120GB limit is not an ATA100 limitation.

Nice troll.

Re:ATA133

[Luminous Coward]

Very interesting. Thanks for the information.

Your "ATA/100" motherboard does not support 48-bit addresing.

Two weeks ago, ASUS released a new BIOS for the A7V133-C motherboard. ASUS claims that version 1009 adds support for 48-bit HDD. Would that mean that the motherboard now supports HDD larger than 120 GB?

Re:ATA133

[Zathrus]

Most likely.

There isn't a physical difference between the cables in the two standards, so it must be possible to support the addressing in BIOS. Barring any issues in the south bridge chipset itself. And based on that I'd guess it is just a software side issue.

Re:ATA133

[Rolo Tomasi]

Well ... with an ATA 100 controller you meet the hardware requirements for LBA48. My Asus P4T has ATA-100 and supports LBA48. LBA48 is part of the ATAPI-6 standard, as is acoustic management, both of which almost all of the current ATA 100 controllers support. ATAPI-6 is not yet ANSI certified, but that has never kept people from using anything. ATAPI (AT Attachment Packet Interface) is actually a protocol to send SCSI-like commands over the (physical) IDE (now UltraDMA) interface, so it's mostly a software issue, except that you need a few extra registers in the controller for LBA48. UltraDMA is a physical interface that is much like IDE, but with improved error correction and using both the rising and falling edge of the signal to transfer data (like DDR). The faster UltraDMA modes then just have higher clockspeeds.

So UltraDMA==physical interface; ATAPI==Protocol.

It's all a big kludge, really. I can't believe SCSI is dying.

Re:ATA133

[gr]

IDE hard drives are pushing the 50mb/s mark. If one should place two of them on a channel and run intense I/O on both you can come fairly close to the 100mb/s barrier imposed by the interface.

Hrm. So what about the fact that I get 160 MB/s out of the (third-party) LVD SCSI in our Suns, and ~200 MB/s off the FCAL array?

IDE is still nowhere in the running for anyone who actually uses real drive capacity and throughput.

ATA133 aleviates another barrier of ATA100 that the IDE drive manufacturers have already begun to run into: The 120gb limit. There are currently 160gb IDE drives on the market, and if one should only have an ATA100 controller in their box they would be losing 40gb. That's no good at all.

This is a *really* important point. I got bit by that one myself for /mp3 at home (where I don't consider my disk needs very significant, which means losing 40 GBs actually matters).

Also, again, IDE's nowhere in the running for real use. If I can't see 2TB+, it's a waste of my (employer's) money.

Re:ATA133

[Anonymous Coward]

It's all a big kludge, really. I can't believe SCSI is dying.

Let's get Apple to put SCSI back in their machines. ;-)

Re:ATA133

[RelliK]

IDE hard drives are pushing the 50mb/s mark. If one should place two of them on a channel and run intense I/O on both you can come fairly close to the 100mb/s barrier imposed by the interface.

Oh, for the millionth time it's NOT! IDE is a very dumb interface. Only one device per channel can work at a given time. While you are reading/writing one drive, the other one does absolutely nothing. It is not possible to get sustained transfer of anywhere near 100MB/s out of IDE. This is precisely why people report no improvement in speed when going from 2x striped IDE RAID (on 2 separate channels) to 4x. If you want the 4 drives to work at the same time, you have to use SCSI.

To sum up, anything above ATA66 is a marketing gimmick (I have yet to see an IDE drive that can have sustained transfer of over 50MB/s). ATA133 is not entirely so -- it allows you to use HDs of > 120GB, but that's it.

Re:ATA133

[Zathrus]

Thanks for the clarifications.

And yes, it is a big kludge. But so is the 80x86 instruction set and the entire core PC bus (keyboard on IRQ 1? WTF?). They're all successful because they're low cost and they really do work pretty damn well.

I have an older system running all SCSI drives... I'm planning on popping in a 20 GB IDE and CD-RW. I expect disk speed to at least double. SCSI-II is sloooooow by modern standards, and a new SCSI CD-RW costs more (and is slower than) an IDE HD and CD-RW combined. Sad, but true.

Re:ATA133

[Anonymous Coward]

It's not a troll in the usual slashdot sense.

I just reposted a random comment from the board on the linked site

It's a 0day warez comment if you like :)

Re:ATA133

[Anonymous Coward]

So are you saying the 1 drive per channel limitation has been removed? Last time I checked, putting 2 drives on a single IDE channel killed performance. Ever try to burn a CD at 32x when the burner and source drive are on the same IDE channel. Doesn't work. You may as well stick with ATA/33 if you're putting multiple drives on each channel.

Re:ATA133

[spektr]

Only one device per channel can work at a given time.

So what? ATA100 transferes at 100MB/sec, regardless of the speed of the drives attached. If the drive can deliver 50MB/sec, the data will go over the bus at a speed of 100MB/sec and the bus will be idle half of the remaining time (where the other drive has the chance to transfer). So, in theory, two drives at 50MB/sec will push 100MB/sec over the bus. In reality there are some losses, though...

The main point why ATA133 is pointless (speedwise) is that we don't have IDE-drives yet which can transfer much more than 40-50MB/sec. So ATA133 can't bring a performance win over ATA100, because the bus simply isn't a bottleneck.

Re:ATA133

[Anonymous Coward]

No, you just described SCSI. IDE can't fill in the idle time. The channel is tied up until the requested read is complete.

Re:ATA133

[Artifex]

This was an excellent response.

That being said, I think my major worry is not that I might start saturating my bandwidth to my storage system, it's that my storage system (7200 RPM hard drives) could fail at any time. This is due to all the media attention on the recalls and the low margins on all of these drives.

Frankly, I'd pay 50% more for the piece of mind that I won't wake up tomorrow to find that my data is gone. So far, that's not enough to justify the cost/performance hit of redundant drives in a RAID, but it's getting there (I already have the adapter on hand)...

Re:ATA133

[Billnvd65]

Wrong, Wrong and WRONG!!!

Two IDE drives cannot R/W at the same time on one channel. This has been explained like a million times. If Drive A is reading at a full 50MB/sec, it is using the Channel during that time period. The other drive is idle. For Drive B to R/W on that channel, Drive A has to stop R/W and let B use the channel. Two 50MB/sec IDE drives on one channel will NOT yield anything but 50 MB/sec xfer.

For proof of this particular shortcoming, try a large file copy between two IDE drives on one channel. Assuming two identical HD's, the xfer will take twice as long compared to those same drives on seperate channels.

The reason? ONLY ONE DRIVE CAN ACCESS THE CHANNEL AT ANY GIVEN TIME! If drive a is reading at 50MB/sec, it needs the channel for the entire second, drive B will not get a chance to transfer any data until Drive A is done.

In all reality, trying to read from two IDE drives on the same channel gives really bad performance due to the overhead of the drives actively taking control of the channel.

So two 50MB/sec drives being asked to read at the same time will not even yield 50MB/sec, but more like 30MB/sec as so much time is lost in switching which drive is talking on the bus.

Bill

Re:ATA133

[Anonymous Coward]

Serial ATA is really bad in delevering good speeds. We are allready in a enviroment where we think a HDD on a IEEE 1394 interface is too slow for desktop use.

Rotating media

[yerricde]

Perhaps it is simple a case of the technology being too young to actually realize the 33% expected increase in performance

The sustained transfer rate of a hard disk cannot exceed the amount of data per cylinder times the rotation speed of the platter. In addition, HD designers are not easily going to overcome the fact that it takes a while to move the head from the inside to the outside of the platter.

Re:Rotating media

[ObviousGuy]

Thanks for the info.

Re:Rotating media

[earlytime]

maybe one day they'll figure out how to make dual read heads with independent actuator arms (i.e at 0 degrees, and at 180 degrees) on the same platter. Then your 7200 rpm drive can blow the pants off of those turbojet 15Krpm monsters.

Re:Rotating media

[13Echo]

Which is exactly why my ATA100 drives are faster at burst reading than my friend's ATA133 drives. His drives have a minor advantage at writing though.

No amount of explanation could convince him that ATA133 drives weren't any faster than ATA100 drives. He was blinded by the numbers.

Re:Rotating media

[ncc74656]

In addition, HD designers are not easily going to overcome the fact that it takes a while to move the head from the inside to the outside of the platter.

They haven't exactly been making much progress here, either. Compare the seek-time specs for the Seagate ST15150W, one of the first 7200rpm hard drives, to the Western Digital WD1200JB, one of the most advanced IDE hard drives currently available. The ST15150W (Barracuda 4) has been around for years, but it still boasts faster track-to-track, full-stroke, and average seek times. IME, while the sustained data rate from the 'Cudas isn't that impressive (I measured about 6 or 7 MB/s from them once), it'll still deliver better small-file and medium-file performance than many newer drives...especially IDE drives, and especially if you have lots of scattered accesses going at once.

If you have the money for SCSI or Fibre Channel, you can get faster seek times with current products (the ST336752LW boasts a 4-ms average seek time and a full-stroke seek time faster than other drives' average seek time...being a 15krpm drive also doesn't hurt :-) ). Migrating this kind of performance into desktop IDE hard drives would make more of a difference than ATA133.

Re:Rotating media

[frozenray]

>maybe one day they'll figure out how to make dual read heads with independent actuator arms (i.e at 0 degrees, and at 180 degrees) on the same platter.

The Seagate Barracuda 2HP used dual read/write heads to achieve blazing (for that time) performance - 2HP is short for "Two Heads Parallel".

See also this page, which has a write-up on the 2HP and why the concept ultimately did not catch on, as well as some other examples of unusual disk technologies.

Re:Rotating media

[jrwyant]

Additionally, the speed improvement of ATA133 vs. ATA100 is _only_ on the read datapath. In other words, the reads occur at 133 vs. 100. The driver still has to do the same number of Programmed I/O ("PIO") cycles to set up a data transfer; the writes still occur at roughly ATA88 speed. So, as the read speed increases, you're improving an ever-increasingly insignificant portion of the pie. At that point this is merely marketing bullet-worthy. :)

Effort outweighs the gains

[jason99si]

This story hits far too close to home as I just spent the last two evenings attempting to install my Promise ATA/133 card, along with my new Maxtor 160gb drive.. and a new install of Windows. Although I had the most recent drivers, and specified them on install, Windows XPlod could not manage to complete an installation without a hard freeze, blue screen, or other nonsense. I tried with Linux, but only managed to lose my MP3 collection on my other drive. Windows 2000 finally did go.

I'm convinced that even if it yielded a 20% increase in performance it wouldn't be worth complicating my install, my boot time, my lack of slots on my board, etc.

Meanwhile, my lawn has grown out of control, and the trash is starting to stink from me neglecting my other tasks. My advice, ditch the controller for ATA133, and live your life.

RAID

[faldore]

I'd be more interested in the RAID capabilities of the motherboard than the upgrade from ATA100 to ATA133. Besides, hard drives are so much faster than CD-ROM drives that they are all pretty much the same. I actually got a "faster" ATA100 hard drive (60 GB) that goes slower in real life than my old ATA66 20 GB hard drive. 1) benchmarks don't always reflect real life 2) speed doesn't really matter with hard drives since they're so fast anyway.

Re:RAID

[Shanep]

I actually got a "faster" ATA100 hard drive (60 GB) that goes slower in real life than my old ATA66 20 GB hard drive.

What models are you comparing and did you set them up so that they were running at their best settings? I'm assuming you're using a free Unix and tweaking with hdparm? I would be shocked if the fastest 20GB drive is quicker than the slowest 60GB drives of today.

1) benchmarks don't always reflect real life

Actually, they usually do reflect very closely, small areas of real life performance. People just don't know how to interpret the results.

People don't tend to realise that this so called "real World performance" is actually made up of lots of extremely varying little performance bottlenecks which add up, but each of which can be measured.

2) speed doesn't really matter with hard drives since they're so fast anyway.

Huh? My PII-300 PC100 SDRAM transfers at about 800MB/s if I remember correctly, but a fast ATA HDD might transfer at 45MB/s on a 66, 100 or 133MB/s ATA bus. Disk media is slow as molasses compared with most of the rest of computer systems. Besides tape of course, which is a horse for a completely different course.

Re:RAID

[Anonymous Coward]

Reality check. PC100 SDRAM CPU to memory is about 200MB/s according to STREAM. Drives don't get better than perhaps 45MB/s for outer diameter of platter and more like 25MB/s for inner diameter, but this is for a strictly linear transfer from platter to RAM and does not accomodate the +7ms AVERAGE seek time.

Re:RAID

[Shanep]

Reality check. PC100 SDRAM CPU to memory is about 200MB/s

No, you are in serious need of a reality check. My 512MB of PC100 SDRAM benchmarks as being around 800MB/s with memtest.

Here are a couple of web sites that agree with this also...

http://www.a1-electronics.co.uk/Memory/SDRAM.sht ml
http://www.pcmech.com/show/memory/154/
http:/ /www.savingxoom.com/ddrmemory1.html

Should I provide more?

Drives don't get better than perhaps 45MB/s for outer diameter of platter and more like 25MB/s for inner diameter,

Western Digital Caviar WD1200JB: 48.8MB/s outer, 29.2MB/s inner.

The Seagate Cheetah X15-36LP does 60.5MB/s outer and 45MB/s inner, for a comparison of a 15k SCSI drive, with a 5.9mS access time.

but this is for a strictly linear transfer from platter to RAM and does not accomodate the +7ms AVERAGE seek time.

Is it not obvious that I am speaking purely about maximum sustained transfer rates? You can't get the maximum values if we're not talking about sequential transfers. But thanks for the pointer AC.

Re:Oooh,Ah Faster faster faster!!!

[OpenSourcerer]

Offtopic? friggin moderators! Me thinks the best way to Karma whoring, just copying and pasting the text :-(

Best way to increase hard drive performance:

[leviramsey]

Slap a type-R sticker on your drive. I did it, and I swear I got an extra MB/sec out of my ATA/100.

I'm thinking of putting a spoiler on it. I figure that's good for at least 850KB/sec. Any recommendations?

Re:Best way to increase hard drive performance:

[Anonymous Coward]

headers, duals, supercharger & nitrous oxide injector...

don't forget the fuzzy dice...

Re:Best way to increase hard drive performance:

[sacremon]

How about bigger exhaust fans, a higher wattage PSU and supercharging the spindle motor to 10K RPM?

Re:Best way to increase hard drive performance:

[Anonymous Coward]

Pssshhh...

All you need is a big ass spoiler.

Re:Best way to increase hard drive performance:

[dingo]

Hands down best way is to paint it red.Metalic red preferably.

Re:Best way to increase hard drive performance:

[Enry]

I think the problem is that 50-pin catalytic converter they have on there. If you're not driving on streets, I'd recommend getting the 68 or 80 pin. More expensive, but worth it in the end.

Oh, and a bass tube works wonders too, especially if you're driving an MP3 database.

Re:Best way to increase hard drive performance:

[Confuse Ed]

Get a roundabout (don't know where you buy them from, but all kids playgrounds have them....) and put it in your computer room, then mount your computer in the middle of it, and spin it up ....

You should be able to get an extra 50 RPM out of it, but you might have trouble with your mouse moving due to centrifugal force...

Re:Best way to increase hard drive performance:

[thesolo]

Any recommendations?

For you, I have one word: stripes! Preferrably fat, double-yellow ones.

Seriously, they make everything go fast!! Your drive will be screaming. ;)

Re:Best way to increase hard drive performance:

[Skweetis]

Don't forget the stylized chrome mounting screws, those are good for at least another 1200KB/sec. :)

Re:Best way to increase hard drive performance:

[Jburkholder]

Heh, give your harddrive the riceboy treatment, eh?

I vote for fog lights, VTEC emblems and 4 inch exhaust tip. That should really boost performance!!!

Re:Best way to increase hard drive performance:

[Pogue Mahone]

Call me old fashioned, but I reckon you can't beat go-faster stripes down the sides.

Re:Best way to increase hard drive performance:

[yuri82]

It's been done, and I hear the chicks dig it! Check it out over here: TypeR The got rice sticker is optional.

Re:Best way to increase hard drive performance:

[America Uber Alles]

If you really want to increase performance, what you need is top-of-the-line soundcard and speakers. If you haven't spent more on your sound system than the rest of your computer, then you're not using your computer effectively.

Re:Best way to increase hard drive performance:

[b1t r0t]

Silly boy. Everyone knows that yellow is the fastest color. Red, being the second fastest color, is used for decals.

FWIW, A few months I saw a ricecar with a ton of decals on it, some of them even referring to decal companies. One of the decals said "VINYL INCREASES HORSEPOWER". I am not making this up. This was one riceboy who knew how silly ricecaring was, and loved it anyhow.

Re:Best way to increase hard drive performance:

[NuShrike]

Slap on some Mugen stickers. Each should good for 500KB extra performance.

While you're at it.. slap on a Spider sticker, some aerodynamic flares on the edges of the HD, polished chrome rails, Koni rubber shock absorbing screws, Iceman mandrel bent HD forced air cooler with K&N filters, connect the turbo button on your case to a NOS injector to squirt on your CPU. ;)

That should do it! Going by some of the stuff listed at RaceSearch

Re:Best way to increase hard drive performance:

[ThatComputerGuy]

Grab some spraypaint. An extra stripe will get you a few MB/s, and logically 2 stripes should easily double that.

Also try putting the whole thing in a coffee can, so all the heat from the exhaust can vent out and you'll get that much better performance.

Re:Best way to increase hard drive performance:

[tswinzig]

Slap a type-R sticker on your drive. I did it, and I swear I got an extra MB/sec out of my ATA/100.

I'm thinking of putting a spoiler on it. I figure that's good for at least 850KB/sec. Any recommendations?

Two words: Nitrous Oxide!

Re:Best way to increase hard drive performance:

[sharkey]

Rework the width with rails. They screw onto the sides of the HDD, and make it 5.25 inches wide, instead of a pussy 3.5 inches.

Re:Best way to increase hard drive performance:

[jafac]

whachya REALLY should do is get a car made prior to 1972, and tell the EPA to fuck off. (regulations vary by state). No catalytic converter, and carbs running so rich you can smell the gasoline in the exhause. Yeah baby, that's the way to go.

Re:Best way to increase hard drive performance:

[Anonymous Coward]

Nitrous Oxide

WHeeeeeeeeeeeeeeEEEEEEEEEEEEEEEEEEEEEEEEEEeeeeeeee ee!

Re:Best way to increase hard drive performance:

[neafevoc]

Don't forget about getting a 3-button Logitech mouse. :)

Re:Best way to increase hard drive performance:

[Anonymous Coward]

You could also take the ball end of a ball-peen hammer to your hard drive. All those little bumps on the surface will improve its drag coefficient significantly. You'll even get better gas mileage!

Re:Best way to increase hard drive performance:

[56ker]

That is a nice sticker - but what's the "Got Rice" slogan about?

Digital Audio benchmark

[GusherJizmac]

The biggest reasons for faster drivers (other than running a file server) would be digital audio and offline graphics rendering. They should show benchmarks on that. There's utilities that tell you, for example, how many audio tracks you can read/write at one time. Comparison to SCSI would be nice, too, since IDE should be a cheap alternative to SCSI for desktop audio users (because SCSI shines with multiple reads, which you don't really need when you want one app to have max. bandwidth to the disk)

I can't imagine that John Q. Photoshop user cares about disk speed; cpu speed is probably more the issue for that.

Re:Digital Audio benchmark

[EddydaSquige]

Actually many photoshop users do care about disk speed. Photoshop is a huge memory hog and its own virtual memory system (adobe calls it the scratch disk). It's recomended that if your going to be working on large PS files that you have a minimum of 2 Gb scratch and I know many people (including myself) who swear by 10Gb. That's a 10 Gb partition, kept clean and only used by PS.

The faster your scratch disk is, the less time PS spends pageing, this can add up to over a 30 second savings on complex filters or actions. Check out barefeats.com for benchmark tests related to graphics a video programs.

Re:Digital Audio benchmark

[Shanep]

I can't imagine that John Q. Photoshop user cares about disk speed; cpu speed is probably more the issue for that.

Disk speed is a massive bottleneck if John Q. Photoshop user does not have enough RAM to hold his Photoshop sessions entirely.

If he is smart, he would have spent big on RAM, then CPU and then disk. If he is a serious Photoshop user, then he would have maxed out in every dept.

Photoshop eats RAM for breakfast and sporadically CPU cycles. A 2048x1024 true colour image with an 8 bit alpha channel, 5 layers and 10 undo levels will use approx 420MB in RAM, not including OS or application memory usage.

Bandwith not dominating avg speed?

[petis]

results may vary between drives, but the difference in performance from ATA100 and ATA133 is negligible.

If you look at the Read Max/Min/Avg values on page four they are almost the same. This should imply that the time to transfer the data is small compared to finding it on the disk. I think. Is that correct?

Re:Bandwith not dominating avg speed?

[Shanep]

If you look at the Read Max/Min/Avg values on page four they are almost the same. This should imply that the time to transfer the data is small compared to finding it on the disk. I think. Is that correct?

The numbers are the same because the limiting factor in the whole test is the drive itself. If it can't sustain a transfer rate higher than 66MB/s for example, then a performance difference between 66,100 or 133 could not possibly be measured since the drive is limiting the numbers to what IT is capable of and not what the different bus standards are capable of.

If you have a Ford that is capable of 100km/h, your top speed in a straight line is 100km/h, but will your Ford go faster on a road that allows 120km/h? The car is the limit here.

Two Problems With This Test...

[Handover Slashdot]

One, the main bottleneck in HD's is not the external transfer, but the internal transfer. Even the best current IDE drives only transfer data at about 60-70 mb/sec, making ATA 100 mare than sufficient. Two, the only drive he used in this test was a Maxtor, which is far slower than that (they do about 52-54 mb/sec.) Maxtor is the only major current supporter of the 133 standard, and there may be a reason for that. Try putting the 133 Maxtor up against the Western Digital WD1200JB (currently the fastest IDE HD on the market due to 8mb cache) and see how it fares.

Re:Two Problems With This Test...

[Zathrus]

Your concepts are right, but the numbers are a bit off...

The fastest IDE drives on the market are still maxing out at around 50 MB/s. The WD, Maxtor, and IBM drives all hover around here. WD gets the edge due to cache, but it doesn't really change the diskbuffer speed.

The Maxtor they used would certainly get it's ass whooped by the WD drive you mention - it's a 5400 rpm model and has a max transfer rate in the 40 MB/s range. Ouch.

Funny thing though... of the three companies mentioned above WD is the only one that doesn't publish the actual drive to cache transfer rates. Both Maxtor and IBM publish maximum rates, sustained rates at outer diameter, and sustained at inner. WD only publishes the cache write speed (~75 MB/s) which is meaningless. Benchmarks show the WD drive to have read transfer rates at the same speeds as Maxtor and IBM though.

Re:Two Problems With This Test...

[13Echo]

60-70 MB per sec? Who makes an IDE drive that fast? The fastest that I have seen was less than 50 MB per sec.

I guess that beats my ESDI drive

[tmcmsail]

I am looking forward to the days of driveless machines, since moving parts are what usually breaks.

New Technology is great, lets keep it going!!!

Practicality?

[Shanep]

How many ATA drives out there actually get anywhere near 133MB/s sustained transfer rates from the media? Any even able to sustain half of that? Not that I've seen.

For ATA, it's hype.

Someone might argue that it is good for RAID, which would be true for SCSI. But RAID 0 for example with two drives on the same ATA bus gives terrible performance due to the time taken to switch between ATA master and slave drives. So it really comes down to what an ATA drive can sustain.

Sure it's nice to have the fast bus in place for the future, but by then, you've probably already upgraded to something much faster still.

Re:Practicality?

[flatrock]

Drives are getting into the 50 to 60 MB/s range. You can put 2 drives on a channel, and you want a little head room, because you aren't usually using the bandwidth on the bus optimally. That's also today's drives. I'm sure most people plan on keeping their computers a few years, and would like to be able to take advantage of a drive they add a year or two from now. It seems like 133 MB/s is a reasonable amount of bandwidth for today's drives, with a little room to grow.

Re:Practicality?

[Shanep]

Drives are getting into the 50 to 60 MB/s range.

Fastest ATA drive I have seen to date sustains about 49MB/s. Can you point me to the 60MB/s drive? I'm in the market for two at the moment.

You can put 2 drives on a channel, and you want a little head room, because you aren't usually using the bandwidth on the bus optimally.

Actually, two drives on one ATA bus often hurts performance due to ATA's terrible design. There is an unholy amount of time involved with switching between master and slave that severely hurts these setups.

If you have system files on a master and swap/data etc on a slave type setup, you might be doing yourself a disservice. If you are using some sort of RAID which includes two drives on the same ATA bus (striping, mirroring or part of a RAID5 or other more complex RAID) then the time taken to switch between master and slave is severely hurting performance.

That's also today's drives. I'm sure most people plan on keeping their computers a few years, and would like to be able to take advantage of a drive they add a year or two from now. It seems like 133 MB/s is a reasonable amount of bandwidth for today's drives, with a little room to grow.

It seems to me that drives are getting faster at about 15-20% per year. In about 4-5 years drives that are doing 130+MB/s will probably be only serial ATA or something with fibre optics.

Regardless, you are no doubt using a decent OS which caches your file systems well, in which case, system memory is where people should be putting their money.

Re:Practicality?

[ez76]

Someone might argue that it is good for RAID, which would be true for SCSI. But RAID 0 for example with two drives on the same ATA bus gives terrible performance due to the time taken to switch between ATA master and slave drives.

This is disingenuous because few two-drive ATA RAID 0 systems are configured with both drives on the same channel. All ATA RAID solutions have at least two independent channels and it is the norm to put a single drive as master on each.

Re:Practicality?

[Shanep]

This is disingenuous because few two-drive ATA RAID 0 systems are configured with both drives on the same channel. All ATA RAID solutions have at least two independent channels and it is the norm to put a single drive as master on each.

Thus my point?

That is exactly my point. Few ATA RAID designs use more than one drive per channel exactly because the time to switch between master and slave is so poor that performance is hurt so baddly.

Thus, ATA bus speed should never be considered "headroom" for extra performance gained through any RAID design, because it's not going to happen.

ATA bus speed should only be considered a top speed per device, if that device were capable.

Re:Practicality?

[ez76]

I see your point and you are absolutely right that ATA133 would do nothing for ATA RAID, speed-wise.

Re:Practicality?

[Shanep]

It's a shame though, since ATA drives by themselves are so quick (sequentialy speaking), compared with SCSI.

It would be great to see future ATA standards get some SCSI features that would enable same channel RAID performance.

I have been wondering how RAID would perform over Firewire with multiple Firewire/ATA drives. Possibly a poor mans "SCSI400"? Capable of hotswapping and all.

Re:Practicality?

[ez76]

I have been wondering how RAID would perform over Firewire with multiple Firewire/ATA drives. Possibly a poor mans "SCSI400"? Capable of hotswapping and all.

But Firewire is (currently) 400Mbps = 50MB/s so it doesn't sound like you'd be that much better off? How much time does the ATA master/slave transition really take?

Re:Practicality?

[Shanep]

Oh bugger, I thought it was MB and not Mb. Thanks for pointing that out.

The Software RAID howto for Linux briefly mentions the problem, but does not delve into the cause...

http://www.tldp.org/HOWTO/Software-RAID-HOWTO-2.ht ml#ss2.1

I'm searching for some numbers at the moment that might hopefully show how bad the problem is with a RAID0 setup. I guess the problem would be worse the smaller the chunk size.

What this is trying to say is...

[ogar572]

unless you are really, really, really, impatient and can't what that extra couple nanoseconds to listen to your mp3s or open your browser, you don't need to go out and upgrade right now.
It is like going out and buying the newer model car every year just because it is out when you really don't need it.

Re:Effort outweighs the gains

[joebp]

This story hits far too close to home as I just spent the last two evenings attempting to install my Promise ATA/133 card, along with my new Maxtor 160gb drive.. and a new install of Windows. Although I had the most recent drivers, and specified them on install, Windows XPlod could not manage to complete an installation without a hard freeze, blue screen, or other nonsense. I tried with Linux, but only managed to lose my MP3 collection on my other drive.

FYI, my backup server has a Promise Ultra133 TX2 with two Maxtor 160GB drives, running stripped-down Mandrake Linux quite happily.

Personally I think that ATA133's biggest advantage is the support for drives over 137GB. The speed constraint is a secondary advantage.

Say PCI bottleneck!

[Gruturo]

Maybe we're forgetting that the "normal" (32bit, 33Mhz) PCI Bus has a total bandwidth of (32 bits = 4bytes) * (33Mhz) = 132 Mbytes/second.

Now, this is the total BUS bandwidth, with 2 EIDE channels and all the other PCI stuff you've got on the 'puter sharing this resource. Luckily, AGP cards don't have to share that same bandwidth, but, heck, how can you even hope to get close to 133Mbytes/second from your hard drive(s) on such a bus, even if they could (and they can't) actually spew out that much data?

Until they start designing southbridges with multiple PCI busses and the embedded EIDE attached to one of those, all of this is plainly pointless. Many really high-end chipsets as ServerWorks' already do this, but they cost so much that in that case you'd go for a SCSI subsystem anyway :-)

Much more welcome is the ability to overcome the 120GB limit, instead.

Re:Say PCI bottleneck!

[Anonymous Coward]

The link from the southbridge (which hosts the PCI controller) and the northbridge is 266MB/s in VIA chipsets, going up to 533MB/s this year, 266MB/s in Intel chipsets, going up to 533MB/s this year, 800MB/s in nVidia chipsets, 533MB/s in SiS chipsets (1GB/s in their single chip chipsets).

Southbridges are no longer PCI devices themselves. They are more an extension of the northbridge itself, with an interconnect to allow two separate physical chips to be used.

What you wrote is correct a year or two ago when the southbridge was simply a PCI device sharing the bandwidth.

Re:Say PCI bottleneck!

[IsleOfView]

Maybe we're forgetting that the "normal" (32bit, 33Mhz) PCI Bus has a total bandwidth of (32 bits = 4bytes) * (33Mhz) = 132 Mbytes/second.
...
Until they start designing southbridges with multiple PCI busses and the embedded EIDE attached to one of those, all of this is plainly pointless. Many really high-end chipsets as ServerWorks' already do this, but they cost so much that in that case you'd go for a SCSI subsystem anyway :-)

I'm probably being really ignorant here, so please enlighten me :). Even if you do go for SCSI, most SCSI cards still plug into those same old PCI buses --- you're still hit with the same performance problem when shoving data through that pipe. right?

Re:Say PCI bottleneck!

[mattdm]

Yes, definitely. However, many server/workstation scsi cards plug into 64-bit pci slots, for twice the bandwidth. (No reason to do that with IDE yet, because if you've got money....)

Re:Say PCI bottleneck!

[Anonymous Coward]

I think he was talking about that multiple pci bus SCSI card drool.......

Re:Say PCI bottleneck!

[Gruturo]

I know. I have an Asus A7V333/RAID with KT333 and a 266MB/s V-Link bus joining the North and South bridges. It has integrated Ata100 within the southbridge (VT8233A) and a Promise ATA133 (only recognized by 2.4.19pre7 and up) raid controller also sitting on the mobo. According to /proc/pci they are all sitting on the same PCI bus, while on a ServerWorks CNB20LE machine @work I see the dual-channel scuzzy controller sitting on PCI bus #1 (the other PCI stuff shows up on bus #0).

My point is:
1) I'm not even sure that the Southbridge's builtin EIDE controller actually sits on a different path than the rest of the PCI stuff (http://www.via.com.tw/en/apollo/KT333.jsp).
2) Even if it would, surely the add-on (although integrated in the mobo) raid controller is sharing PCI bandwith.
3) Those IDE channels alone could theoretically create 466 MB/second, without even considering any other PCI cards you might have. Even the amazing 266MB/s V-link suddenly doesn't seem so wide :-)
4) You say that this stuff was correct 1-2 years ago. KT133A motherboards are still sold today and they use PCI to link North and South bridges. Granted, Intel's 82801BA ICH2 does use a hi-speed hub and seems to have different internal "ports" for the IDE busses (they are indeed enumerated separately), so you'd have to go wayback to 440BX to get a PCI southbridge (82371AB)

Re:Say PCI bottleneck!

[Gruturo]

I'm probably being really ignorant here, so please enlighten me :). Even if you do go for SCSI, most SCSI cards still plug into those same old PCI buses --- you're still hit with the same performance problem when shoving data through that pipe. right?

Yes. That's the reason those higher speed Scuzzy (Ultra-160, Ultra-320) and Gigabit Ethernet controllers tend to use 64bit slots.

PCI can be 33 or 66Mhz, 32 or 64 bit. What we usually have is the lowest-end (33Mhz,32bit), but variants have been around for ages (look inside a Sun Enterprise 420, for example), they just don't usually appear in normal PCs.

Re:Say PCI bottleneck!

[Anonymous Coward]

Why is the parent only +1? It's correct as opposed to the parent's parent. ... which is absolutely redudant and false.

Re:Say PCI bottleneck!

[Anonymous Coward]

1) It does. It could be a side effect of v-Link that makes the OS think that it is sitting on the PCI bus however, but the integrated ATA133 will not use up any of the PCI bus bandwidth - same as the integrated USB, etc, will also not use that bandwidth.

2) Yes, the PCI RAID controller will be sharing bandwidth

3) All 4 channels could create 466MB/s, but 99.999% of the time you will not be accessing them all at the same time, and you won't have drives that can use all of that bandwidth anyway. If we assume (on the PCI side) a striped RAID array of 60MB/s disks I can see bursts of 120MB/s on the PCI bus however (not that PCI actually can handle that much in real life).

4) KT133A based motherboards are low-end though. Durons, 30MB/s hard drives, etc, now.

Re:Say PCI bottleneck!

[stapedium]

This is probably a dumb question, but for copying from disk to disk, why does the data have to travel across the PCI bus at all?

Re:Say PCI bottleneck!

[excaliborg]

it gets stored in the ram i think, so it has to go through the PCI

Re:Say PCI bottleneck!

[jrwyant]

Don't know about SCSI drivers, but with IDE the data stream goes from drive to host (computer) memory, there's no path from Drive to Drive (master to slave or vice versa.) Additionally, each controller (primary and secondary) are effectively copies of eachother (just with their registers at different I/O offsets), so again software drivers are limited to drive to host memory transfers, not drive to drive. It's an IDE architecture limitation. It wouldn't surprise me if the same stood for SCSI.

Re:Say PCI bottleneck!

[jrwyant]

The IDE drives and host controller are designed in a very simple way, in which the host can only take data from the drive straight to memory. The most efficient IDE data transfer method is through DMA (direct memory access) where the IDE host controller logic takes data from the drive and places it in memory. (This requires no direct involvement in the CPU, other than setting the transfer up.) So, drive to memory, no opportunity for drive to drive.

On the other hand, for PIO (Programmed I/O) IDE cycles, the CPU has to actually move the data around byte by byte from memory to drive, which prevents the CPU from doing other work in the mean time (so the DMA is preferred), but I can't think right off why the CPU couldn't take data from one drive in PIO mode, and write it to the other (in PIO mode also.) Both data streams would have to be synchronized pretty closely. *shrugs* Don't know.

IDE vs. SCSI revisited

[blankmange]

Must be an exceptionally slow news day here at /. because this is not news. Granted, there is something interesting hardware here (check out the Western Digital 8mb cache drives :)...), but the comparisons have been done, the benchmarks have been posted and mobos are available (and have been) with ATA133 on them. This is just another opportunity for the SCSI vs. IDE camps to jump up and down at each other and show each other why they are better than the other guys.... I did even see the obligatory beowulf cluster post on this one...

NO, a FAN is what is needed!

[leuk_he]

Slapping a fan on a HD won't make it go faster. It might be the cooling solution you need to keep it going at all. And it makes this "turbo" sound.

And from 1993.. 133Mhz computer faster than 100Mhz

[wackybrit]

Yes, really. It was quite a shock at the time, but it's true, the 133Mhz unit ran rings around the standard 100Mhz box. What's more, it was 33% faster! Fancy that!

+33%? Yawn.

[ferreth]

Feh. An extra 33% bandwidth. Woopee. Considering all the other factors affecting the performance of a system I really don't care unless performace is 2x of what I got, as the net effect is so diluted by the other componets of a system.

Breaking the 120 GB barrier is significant at this point the way HDD capacities have been increasing though.

Percentage difference is what counts

[march]

This is the common misconception with upgrades. Yeah, 133 is faster than 100 but by how much in terms of percentage gain? Not very noticible, as is shown in the article.

People always *have* to have the fastest. Me? Two generations behind the latest is still really fast for 99% of what I do (heck, Unreal Tournament on a PII450 with an older 3d card rocks!).

Even if you saw a 50% increase in speed, how much would it affect your day-to-day operations? And... we're not even clost to that number here.

Re:And from 1993.. 133Mhz computer faster than 100

[qurob]

The real battle in 1995 (actually) was 133mhz vs 150mhz

Bus speed vs CPU speed! hahahahah!

Visual Representation of enhanced speed:

[Matey-O]

ATA100: ***
ATA133: ****

*=33

Any questions?

Re:Visual Representation of enhanced speed:

[Joe Mucchiello]

That's not how you market stuff. You do it like this:

ATA100: o//o
ATA133: o//oooooooooooooooooooooooooooooooooo

o = 1

See that. It's vastly improved.

(Converted to o's to avoid the lameness filter)

Re:Visual Representation of enhanced speed:

[Citizen of Earth]

ATA100: ***
ATA133: ****

But if you were to attach these interfaces to actual hard drives, the comparison would be:

ATA100: *½
ATA133: *½

*=33

120 MB...

[Pig Hogger]

120 megabytes ought to be enough for everyone...

Perspective

[Yoda2]

While the ATA133 appears to be only slightly faster than the ATA100, it demonstrates considerable speed up over this device.

Re:Perspective

[mccalli]

Bah! You want a speed comparison? Do you want a speed comparison??!!

Ladies, gentlemen and coders: I give you the Commodore 1541 snaildrive. A joyous piece of design. So elegant, so slim, so quiet, so fast...

Err...well, not quite. This brick of a drive was quite capable of generating localised black holes due to its incredibly weight. Add in the UK power supply, and you could get rid of your house's central heating system.

The speed was so thunderously slow that it was frequently beaten by tape turbo loaders. Yes. Tape beating disk.

You youngsters today, with your ATA this and your UDMA that. You don't know you're born. Why, when I were a lad we had to look on the 1541 as a luxury. Sheer IO heaven.

Bah.

Cheers,
Ian

Lower cpu load

[Anonymous Coward]

The only significant difference I noticed was in the cpu load imposed by the drive. I suspect the only significant performance benefit of this would be in multiple very large hard drives (3x160 GB of MP3's anyone?). Don't know if it would make RAID better or worse though. The principle advantages of SCSI are in large part traceable to the multiple benefits of keeping the load off of the cpu, and what you have to do to make this possible.

benchmarks etc

[Alien54]

Typically, when you boost the performance of one parameter of a system, you do not see the change taking place uniformly across the system. If you increase performance 33% percent, then all other related components should also be increased to see an equivalent boost.

One easy example of this is, for example, email downloads on a dial up modem. Try it with the same 56k modem in an earlier PI or PII vs a newer high end machine. The time to download your 100 email of spam will be much much faster on the new system, even tho it is in fact the same modem.

so minimal change in performance is not that unusual, although I would have expected to see something more.

I imagine it is something similar to to when the MMX feature came out in the Pentiums. If you didn't have software written to explicitly take advantage of the feature, the perfomance boost was minimal. I can even remember doing benchmarkes to processors of different makes and models, running at the same clock speed. Often the the performance boost was only 10 or 15 % between generations, everything else being equal.

Re:Effort outweighs the gains

[Zathrus]

I'm convinced that even if it yielded a 20% increase in performance it wouldn't be worth complicating my install

Unless you're running some really old drives it wouldn't increase your performance at all.

That new 160 GB Maxtor drive only spins at 5400 rpm and has a sustained transfer rate 10-15 MB/s lower than a 7200 rpm drive. Go check out Maxtor's website and look at the product specs in PDF format.

Note, you want the media transfer rates, not the interface transfer rates.

Re:Effort outweighs the gains

[realdpk]

FYI, Promise's Ultra100TX2 supports >137GB drives (I'm using it for a terabyte backup server as well). New ones don't have to be flashed, older ones have to have their BIOS flashed.

Re: 7200RPM speed limit

[King_TJ]

Yeah, I still don't quite understand why IDE drives top out at 7200RPM. If the technology exists to build SCSI drives at 15K RPM, then you'd think it would easily translate over to IDE drives. (Just use the same motors, spindle and bearing assemblies, etc.)

Personally, I've always suspected they've withheld performance on EIDE drives because they're scared that otherwise, their much more profitable SCSI drive sales will evaporate.

As I recall, they didn't even start building 7200RPM EIDE drives until right after SCSI drives got the boost to 10K RPM speeds.

Quick EIDE RAID tip....

[King_TJ]

From someone who just upgraded to on-board EIDE RAID a couple days ago, and pulled out *lots* of hair on it - I can give you a hot tip or two.

It seems that the Promise on-board IDE RAID (found on motherboards like the MSI 845 Ultra ARU) has serious issues with EIDE zip drives.

If you connect a zip drive to your system anyplace (not necessarily to the RAID IDE ports, but on *any* IDE channel), the system won't let you create a bootable drive array. You can install Windows 2000 or XP or what-have-you, load the Promise drivers during boot, and it'll let you get as far as partitioning and formatting the RAID array. Upon reboot though, you'll get the "no valid boot device" message.

To successfully get your OS installed, remove the zip drive first. Do the entire install, and add back the zip drive later. (It'll be fine after everything's installed.)

I did all the BIOS flash upgrades and everything, and nothing resolved this issue. The support sites don't mention it either. You just see misc. posts from people frustrated because they can't get it working.

Re:Visual Representation - Incorrect

[gopher_hunt]

to nitpick,
ATA100: *** = 99
ATA133: **** = 132
*=33

Are there 15k RPM FireWire disks?

[FatSean]

My 15k SCSI drive is load as hell, but seems faster...or maybe I'm deluding myself because of the noise and cost.

Re:Are there 15k RPM FireWire disks?

[flatrock]

Your 15k rpm SCSI drive is likely faster than 7200 rpm IDE drives. It's questionable if it's any faster than a 15k rpm IDE drive would be. Vendors aren't able to get as high of margins on IDE drives, so it's not cost effective for them to make 15k IDE drives. So while the drive may be significantly faster, it's not really because it's SCSI.

Re:And from 1993.. 133Mhz computer faster than 100

[Shanep]

Yes, really. It was quite a shock at the time, but it's true, the 133Mhz unit ran rings around the standard 100Mhz box. What's more, it was 33% faster! Fancy that!

The point here though, is that ATA133 could not be demonstrated to be 33% quicker than ATA100 because the author does not understand bottleneck effects. Even though the ATA133 bus IS 33% quicker than ATA100. ; ) Not that it matters, yet.

Re:Effort outweighs the gains

[John Paul Jones]

Ummm... and my grandmother had a helluva time overclocking her Athlon.

Took me about 20 minutes to install the same hardware in a RH7.1 system. Get the module source, compile, install.

YMMV

-JPJ

48-bit addressing on old motherboards

[Anonymous Coward]

48-bit addressing was implemented in ATA-6 in such a way that any motherboard can support it. Thus, as long as a BIOS update becomes available you can support 48-bit addressing on your ATA/33 machine!

And even if you don't get a BIOS update, as long as you boot out of the first 128GB you can use drivers for Windows to access the whole drive.

I personally write software for a machine with a really old-tyme controller and we are adding 48-bit addressing support.

So don't sweat the hardware.

Alright, who's going to make the 48-bit addressing patch for TiVos?

Re:48-bit addressing on old motherboards

[Zathrus]

Sadly, I think TiVo's (the original SA's at least)are running ATA/33 and don't have any chance in hell of support 48-bit addressing.

I recall an early hack replacing the kernel in 1.3 to support >80G drives though.

Re:48-bit addressing on old motherboards

[Zathrus]

And if I'd bother to READ what you wrote you even said ATA/33 could support 48-bit addressing. Stupid me.

So I guess it could be done, with both a BIOS and kernel hack. And as I said, the kernel hack has been done before. TiVo starts getting real antsy when you talk about mucking with the BIOS though.

Re: 7200RPM speed limit

[Anonymous Coward]

OK, let's say they took a 15K super-reliable server drive and put a ATA controller on it. Now why exactly is it cheaper? Sounds like the same price to me.

The basic problem is that there's different priorites for 'server' and 'desktop' drives (which the industry has mapped onto the SCSI and IDE interfaces respectively.)

Server Priorities:
1) Reliable, Long Warrantee
2) Fast
3) Expandable by adding drives to arrays
...
99) Cheap

Desktp Priorities:
1) Cheap
2) Big
3) No expansion outside of the case
4) Fast
...
99) Reliable

So we get two entirely different classes of drives. You'd like a 15K IDE drive, and I'd like a 160GB 5400 RPM SCSI drive (would fit my cabling setup better), but life ain't fair when you are outside a target market.

Re: 7200RPM speed limit

[Zathrus]

OK, let's say they took a 15K super-reliable server drive and put a ATA controller on it. Now why exactly is it cheaper? Sounds like the same price to me.

Shrug. They are the same. And yet they price the SCSI drive 2-3x the price of the IDE.

Go look back at when both SCSI and IDE drives were commonly available. They had the exact same mechanicals, the only difference was what controller was slapped on top. People disassembled the drives proving this too. And yet there was still a huge price difference, simply because SCSI could command a price premium.

There are certainly heat issues with the higher rotation drives, but realistically I believe the prior poster is correct - companies aren't manufacturing 10k RPM IDE drives because they're afraid of cannabalizing their highly profitable SCSI market. There may also be other reasons - yields may not be high enough yet to supply sufficient IDE drives, and they may feel costs would be too high. But costs and yields improve over time when you need to increase manufacturing capacity. If there's no need there's often little incentive to spend the time and money retooling production.

SCSI may actually be slower...

[Futurepower(R)]

Remember, SCSI may actually be slower on a single-user system. SCSI is faster in systems with simultaneous requests from many users.

Re:SCSI may actually be slower...

[Rasputin]

Remember, SCSI may actually be slower on a single-user system. SCSI is faster in systems with simultaneous requests from many users.

... or simultaneous requests from the same user. For example mpeg'ing music while you edit your web page.

Re: 7200RPM speed limit

[Anonymous Coward]

There are certainly heat issues with the higher rotation drives, but realistically I believe the prior poster is correct - companies aren't manufacturing 10k RPM IDE drives because they're afraid of cannabalizing their highly profitable SCSI market.

No, the original poster is dumb

Re:Effort outweighs the gains

[LogicX]

For the record, XP does not natively support 137GB+ Drives -- see this knowledge base article and accompanying registry hack for how to enable it: Okay, as I went to find that article.. I found it had been deleted.. here is a Deja reference Another search produced this similar link

Re:Effort outweighs the gains

[Anonymous Coward]

I had the same issues. In my experience it's better to wait until support is built into the chipset rather than using a cheeseball third party controller.

Re: 7200RPM speed limit

[Anonymous Coward]

"Go look back at when both SCSI and IDE drives were commonly available. They had the exact same mechanicals, the only difference was what controller was slapped on top."

Yes, but it was only a 20% difference, not the 300% difference you see today. That 20% could be explained by economies of scale, not the black helicopters.

What you guys don't understand is that the drive business is insanely competitive. If a company could make money pushing a product that their competitors didn't have, they would certainly do it. But that makes too much sense, so let's go with the vast Nixonian conspiracy to keep the good stuff out of the hands of the l33t d00ds.

Question about ATAPI cables

[squarooticus]

It's not clear anyone is going to see this above the din, but I figured I'd ask since knowledgable types will probably be here.

What are the chances of me getting a reliable ATAPI Ultra66 cable longer than 36 inches? I don't care what the spec says; I want something that works, whether it's within the spec or not.

The problem is that my motherboard (Tyan Tiger MP) was designed with the ATAPI interfaces on the side of the motherboard next to the bottom of the case. This makes all but the bottom two external drive bays in my full tower unusable by ATAPI devices!

Of course, I'd be more than willing to switch to firewire, but only when native internal firewire drives are cheap and plentiful. I don't want to go with SCSI, b/c the drives are overpriced relative to performance gain.

Suggestions?

ah...

[Cynikal]

now i feel better.. i had bought an ata133 last week but the order messed up and gave me an ata100, but being the impatient geek that i am, i took the 100 and a decent refund in its place, but all the while imagining the lightning fast speeds i would be missing out on now.. but now from what i can tell, the 133 is somewhere in the 2 - 5% better range, and i can handle losing only 5% over the 33% advertized...

ATA 133 vs, ATA 100

[Anna Merikin]

I had a car whose speedometer went up to 100 miles an hour. Then I traded it for a car whose speedo read up to 133, but neither will do more than 38 miles per hour. Why?

Mod parent up, please

[Anonymous Coward]

ATA133 has nothing to do with addressing/drive size. mczak is right, the parent post is dead wrong.

This one goes to eleven.

[dr_bubble]

NIGEL:This is a top to a, you know, what we use on stage, but it's very...very special because if you can see...
MARTY: Yeah...
NIGEL: ...the numbers all go to eleven. Look...right across the board.
MARTY: Ahh...oh, I see....
NIGEL: Eleven...eleven...eleven....
MARTY: ...and most of these amps go up to ten....
NIGEL: Exactly.
MARTY: Does that mean it's...louder? Is it any louder?
NIGEL: Well, it's one louder, isn't it? It's not ten. You see, most...most blokes, you know, will be playing at ten. You're on ten here...all the way up...all the way up....
MARTY: Yeah....
NIGEL: ...all the way up. You're on ten on your guitar...where can you go from there? Where?
MARTY: I don't know....
NIGEL: Nowhere. Exactly. What we do is if we need that extra...push over the cliff...you know what we do?
MARTY: Put it up to eleven.
NIGEL: Eleven. Exactly. One louder.
MARTY: Why don't you just make ten louder and make ten be the top... number...and make that a little louder?
NIGEL: ...these go to eleven.

Disks will always be slow.

[Eskarel]

It's all ridiculous anyway, unless you have completely predictable data access patterns, you're never going to get anywhere near optimal performance out of your drive, and if you had that it wouldn't be an issue since you could build your system to cache the data into memory before you even needed it. Hard drives are constrained mostly by the fact that they're physical, there has been a great deal of technological advancement, and an even greater amount of research into how to optimize file systems and data access which is why hard drive delays are tolerable, but they're still restricted by the fact that in order to access data you have to move a little arm to a certain track and then wait till the data you want appears under the head. That's why, while your processor gets faster and faster, your hard drive probably seems to be getting slower, chips don't have the same constraints on them so they can increase their speed in a way disks as we know them will never be able to do.

What file system??

[ez76]

Why do these tests never mention what file system they're using let alone cluster size, etc.?

I looked but could not find any details in the link - was it FAT? FAT32? NTFS??

Any url?

[TheLink]

That is interesting, any url/docs for more info on that?

My lowly 10GB 5400rpm ATA Seagate seems to do ok on FreeBSD (UDMA on) - I was thinking the responsiveness would suck, but I don't see much diff compared to the servers on SCSIs. Because on that same pc, Win 9x with UDMA on a faster HDD was bad - can't blame Win 9x - probably the antivirus program sucking up CPU - only 533MHz :( ) - some locking even, had to turn off DMA (even new drivers didn't help). Not going to turn off the real time antivirus tho. Another cost of viruses *sigh*.

I'm starting to wonder if someone has done real world benchmarks with the various antivirus programs on. Wonder what CPU speed you need to scanning for viruses at 50+MB/sec and still have enough juice to do other things.

Cheerio,
Link.

Buy two IDE drives.

[TheLink]

At the SCSI drive prices you can buy two or more ATA HDDs+ controller and RAID them - each on separate channel.

For the same price, on a decent O/S, you'll get the same or more performance. And a lot more disk space too ;). Not as flexible tho.

Cheerio,
Link.

You are a subhuman animal who can't look things up

[Anonymous Coward]

Ever heard of research?

You certainly *can* blame the OS...

[billstewart]

Unix, from pretty much the beginning, has always done a good job of cache management, and a heavily-measured-and-tuned job of file system design, while Windows basically never got the concept. (If you don't use the diskdrive when you can use RAM instead, and do better pre-planning of disk accesses, disk performance is less critical, though of course reducing the amount of bloatware and associated swapping also makes a big difference.) This is partly the difference between a commercial operating system and an openish-source university-oriented operating system (i.e. between minimizing ship date vs. maximizing number of scientific papers written about cool optimizations), and also partly because Unix started off supporting a much wider variety of platforms where portability, tunability, and fault-recovery were essential features.

The anti-virus people have certainly done lots of benchmarking, but the most critical way to speed it up is not to scan stuff you don't need to be scanning. Maybe you should be scanning new files acquired from the Internet, and maybe even scanning files you save to disk, but neither one of those is the 50MB/sec disk speed - you don't need to scan a file every time you read it if your operating system can keep track of when it was last changed, and most viruses can be detected in the first block or two of a file, so you don't need to scan the whole body of most files, just the suspect parts.