Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Hardware

Hard Drive Performance - ATA100 vs ATA133 205

Posted by Hemos from the where-to-plunk-yer-cash dept.
Tweaker writes "A short visual guide to the performance advantages of ATA133 over ATA100. Synthetic and real-world benchmarks are also included."
This discussion has been archived. No new comments can be posted.

Hard Drive Performance - ATA100 vs ATA133 More

Hard Drive Performance - ATA100 vs ATA133

Comments Filter:
  • 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.

    • Rotating media (Score:2, Informative)

      by yerricde ( 125198 )

      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.

      • Thanks for the info.
      • 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.

      • Remember, SCSI may actually be slower on a single-user system. SCSI is faster in systems with simultaneous requests from many users.
      • 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 [seagate.com], one of the first 7200rpm hard drives, to the Western Digital WD1200JB [westerndigital.com], 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 [seagate.com] 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.

    • 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 [scsifaq.org] hardware, not EIDE.
      • 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 (Score:5, Interesting)

        by Cramer ( 69040 ) on Tuesday May 14, 2002 @12:48PM (#3517981) Homepage
        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.
        • 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.
    • 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.

  • No shock (Score:4, Informative)

    by supercytro ( 527265 ) on Tuesday May 14, 2002 @08:59AM (#3516525)
    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.
    • "...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

  • 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.
    • 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 (Score:1, Informative)

      by 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.
      • 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.

    • ...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
    • 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)).
      • 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.

      • 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 (Score:5, Insightful)

      by Zathrus ( 232140 ) on Tuesday May 14, 2002 @09:18AM (#3516647) Homepage
      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.
      • 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.

        • 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.
      • 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.

        • Re: 7200RPM speed limit (Score:3, Insightful)

          by 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.
      • 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.

    • 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.
      • 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.
        • 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.

  • Hardly Revolutionary (Score:2, Insightful)

    by delta407 ( 518868 )

    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 :-)

    • 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.

  • ATA133 (Score:5, Informative)

    by Anonymous Coward on Tuesday May 14, 2002 @09:01AM (#3516540)
    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 (Score:5, Funny)

      by SkulkCU ( 137480 ) on Tuesday May 14, 2002 @09:16AM (#3516632) Homepage Journal

      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 (Score:5, Insightful)

      by Rolo Tomasi ( 538414 ) on Tuesday May 14, 2002 @09:19AM (#3516649) Homepage Journal
      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 (Score:5, Informative)

        by Zathrus ( 232140 ) on Tuesday May 14, 2002 @09:41AM (#3516758) Homepage
        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 [t13.org] website for details. Another good reference is ATA-ATAPI.com [ata-atapi.com], along with PC Guide ATA standards [pcguide.com].

        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 (Score:2, Informative)

          by Rolo Tomasi ( 538414 )
          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.

    • 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 (Score:5, Insightful)

      by RelliK ( 4466 ) on Tuesday May 14, 2002 @12:10PM (#3517744)
      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.

    • 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)...

  • Effort outweighs the gains (Score:4, Interesting)

    by jason99si ( 131298 ) on Tuesday May 14, 2002 @09:03AM (#3516552)
    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.
    • 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 [promise.com] 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.

    • 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 [maxtor.com] and look at the product specs in PDF format.

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

  • RAID (Score:2, Interesting)

    by faldore ( 221970 )
    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.
    • 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.

    • 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.

  • Best way to increase hard drive performance: (Score:5, Funny)

    by leviramsey ( 248057 ) on Tuesday May 14, 2002 @09:05AM (#3516570) Journal

    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?

  • 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.
    • 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 [barefeats.com] for benchmark tests related to graphics a video programs.

    • 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.

  • 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?
    • 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... (Score:4, Interesting)

    by Handover Slashdot ( 255651 ) on Tuesday May 14, 2002 @09:08AM (#3516587)
    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.

  • Practicality? (Score:5, Insightful)

    by Shanep ( 68243 ) on Tuesday May 14, 2002 @09:12AM (#3516611) Homepage
    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.

    • 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.
      • 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.

    • 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.
      • 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.

        • I see your point and you are absolutely right that ATA133 would do nothing for ATA RAID, speed-wise.
          • 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.

            • 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?
  • 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...
  • 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!
    • 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.

  • +33%? Yawn. (Score:2, Insightful)

    by ferreth ( 182847 )
    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.
  • ATA100: ***
    ATA133: ****

    *=33

    Any questions?
  • While the ATA133 appears to be only slightly faster than the ATA100, it demonstrates considerable speed up over this device [atari-history.com].
    • Bah! You want a speed comparison? Do you want a speed comparison??!!

      Ladies, gentlemen and coders: I give you the Commodore 1541 snaildrive [tu-darmstadt.de]. 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

  • Gee, a single 7200 RPM 20 gig IDE drive scores about the same on an ATA 133 bus as it does on an ATA 100 bus?

    Imagine that. I never would've thought.

    At the very least, the guy should've used the biggest, fastest, newest ATA IDE drive, or perhaps two of them, in a (still-vain) attempt to saturate the bus.

    This test basically proves nothing to me.

    - A.P.

  • Article: -1 Uninsightful (Score:4, Informative)

    by jstockdale ( 258118 ) on Tuesday May 14, 2002 @10:05AM (#3516883) Homepage Journal
    Couldnt' decide whether to mod or post on this one, but reading some of the comments provoked me into the latter.

    First of all, anyone here actually supprised (once you've actually thought about it, something that i know we often find difficult) that a benchmark of the same drive in ATA-100 and ATA-133 came out to be nearly identical?

    Well, lets do a brief consideration of this outcome. First of all, all of the benchmarks are based on seek times, sustained throughput, or other factors which are all dependant directly on the drive mechanism itself, ie. rpm/quality of read/write mechanism. When the same drive is tested twice it comes out nearly identical. Whoop!

    The only way the ide bus mode can alter the seek times is through command transmission lag, and considering the signal is constricted by the speed at which the signal propigates rather than the width of the signal (as the datapipe is not a constraing factor) their shouldn't be any noticable difference (we're talking ns of access time vs ms of seek time).

    Addressing the sustained throughput readings, the drive itself is agian the limiting factor, with a maximum rated data throughput of around 25-40MB/s (i'm extrapolating from my drive speeds (160 gig maxtors, 5400rpm) as the reviewer didn't list model numbers) which doesn't come near the ceiling of either interface.

    So basically the benchmarks that are being used for comparison are based on the drive alone. I'm not even going to comment on whether or not this is a valid newsworthy story. uhg!

    Anyway, their are a few areas where the bus should play an important role, and thats burst throughput, througput when tested with fast drives, raid/multi-device arraingments, and with large hdds (>120 gig).

    I'd love to see some benchmarks up addressing these specifically. As they might actually yield useful comparisons.

    The burst throughput should reflect the speed linearly, as should the fast drives. However, I would like to qualify that with the fact that if you can find a IDE drive that will do 133 MB/s sustained I'll eat a coaster. I'm not sure how the Slave/Master transition functions differ with two drives on the two controllers, but that might also yield useful results.

    I can directly comment on the 160 gig drives on a 133 controller, and thats to say they show up as 160 gigs apiece, as they should! So there alone is a reason to get ATA-133. No reason to waste 40 gigs because you couldn't be botherd spending an extra $20 for a faster controller.

    Finally, just to say that anyone thats seriously lookinging into hdd performance as a mission critical component of their operating practice should be ashamed for even considering this debate. SCSI. There is no comparison no matter what anyone will tell you. The drive have always been faster, and as long as the demand can sustain the development of the technologies, they always will be.

    Flame away.

    -John

  • Use the Docs (and the HOWTO) (Score:2, Informative)

    by Anonymous Coward
    This isn't much of a surprise for those who cared to read some documentation (and no, that is not like cheating). I imagine free docs appeals the most to readers here so I will therefore recommend the Multi Disk HOWTO [nyx.net] and the links therein.

    Read it and you will see that the test done was one of the less favourable setups that you could have performed.

    The command overhead for (E)IDE is less than for SCSI though there is no reliable command queueing in (E)IDE in most OSes yet. BSD has it and it is in recent Linux 2.5.x series, though recent summaries on Linux Weekly News [lwn.net] show this is not without problems. With this in mind it is easy to see that long, fast, sequential transfers is the type of tests you want to do to make IDE-133 shine. No this is still not cheating, it is very relevant in applications such as video editing (and streaming) on a 2-4 disk RAID0 setup as the sole disk activity. Had they tested large file download using RAID 0 you would have seen this. And they didn't. Do please keep the constraints in mind, they are very important, it is no surprise that seek time is no better than IDE-100 and seek is a killer in streaming.

    The Multi Disk HOWTO [nyx.net] describes such setups; there is a reason why you have to think a bit to make the optimum arrangement. Some example layouts are here [nyx.net] and here [nyx.net]

    Ok so what is a good test setup to test for actual improvements? Try this: use 2 or 4 disks in RAID [nyx.net] 0 using ext2fs and large block sizes, comparable to disk cache size (perhaps half or quarter that size), freshly formatted and used only for a single large file (keep all other OS and application stuff on another drive) and tune to the max [nyx.net]. Then do a write test and read test using file sizes at least double that of your RAM size, or use Bonnie (or Bonnie++) (see HOWTO for benchmarking links [nyx.net]).

    So what happens? You read one block from one drive while the other (or other 3) drive(s) do a readahead into their caches so when you query next drive the information is already in drive cache so you get max interface speed rather than being limited by platter speed, usually at 30-50 MB/s on recent IDE disks.
    Same for writing, though you write to cache and then the drive writes cache-to-plater while you are busy writing to that other drive(s).
    maths is simple: a 2 drive setup buys you a 2-to-1 speed advantage in the interface-cache-platter transfer. Take the numbers: 133MB/s max transfer (actuyally lower, see those whitepapers meationed) and divide by platter transfer speed, 40 MB/s and you get a 3-to-1 or 4-to-1 ratio which you can cover by 4 disks in RAID 0; it fits beautifully.

    Conclusion: IDE-133 is good for some applications but will buy you very little for normal multi threaded read/write stuff.

    Looking elsewhere on the net it is clear that IDE-133 is a stopgap because SerialATA [serialata.org] is not yet out in volume and that has a transfer rate of about 150MB/s. Factor in the IDE protocol overheads (surprisingly honestly described by vendors (link in HOWTO again)) that difference will not buy you much either. Best thing with SerialATA is that the cabling is less painful. I do hope they will implement Tagged Command Queueing (TCQ) widely since that will make the extra interface speeds more generally useful.

  • 120 megabytes oughtto be enough for everyone...

  • This is news? (Score:3, Insightful)

    by Anonymous Coward on Tuesday May 14, 2002 @12:38PM (#3517906)
    Is there a single geek on slashdot that doesn't understand that even the fastest ATA drives can't come close to saturating an ATA/66 channel, let alone ATA/100 or ATA/133?

    Since IDE doesn't handle two devices per channel very well, you don't have the multiple-device advantage of SCSI. While an individual SCSI drive could never suck up 160mb/sec, 4 of them could do it easily. U160 makes sense. ATA/133 does not.
  • 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??

Slashdot Top Deals

Living on Earth may be expensive, but it includes an annual free trip around the Sun.

Close