Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Hardware

What is Ultra DMA? 35

DAQ42 asks: "Okay, so I've been reading these illusive and cryptic things about ATA hard drives and Ultra DMA settings. There are all these wonderful charts and diagrams everywhere that show the different DMA modes and what they mean as far as seek time and transfer rates but what do they mean to me, the guy who wants to make his hard drive that is set to DMA mode 2 (33.3MB/sec) and set it to DMA mode 3 (66.6 MB/sec). These fun little things make my head go foop. I've seen plenty of stuff about writing or editting your own device drivers for Linux but what about for those of us using fun gimpy stuff like Macs or PC's or other evil toys of destruction."
This discussion has been archived. No new comments can be posted.

What is Ultra DMA?

Comments Filter:
  • by Anonymous Coward
    I doubt you're stating what McKusick said accurately. I honestly don't know what he said at the conference but we all know that ATA PIO-4 is 16.7MB/s. It doesn't take a rocket scientist or McKusick for that matter to realize that bus can be saturated with two good drives.
  • by Anonymous Coward
    I've seen plenty of stuff about writing or editting your own device drivers for Linux but what about for those of us using fun gimpy stuff like Macs or PC's or other evil toys of destruction.

    Boy, that's really informative. Do you just get automatic points for anything related to Linux? I mean, hey, the poster quite clearly implied (didn't say it explicitly) that there's plenty of info out there for Linux, but you decided he needed more. Maybe by ignoring his asking for info on Mac and Win we'll win him over to the 'light side' and trick him into using Linux. Heck, the fastest stuff is still SCSI, why not just completely ignore his question and give him SCSI configuration info, because hey, YOU think he should be using SCSI.

  • by Anonymous Coward
    you forgot the 80 pin cable.
  • by Anonymous Coward on Tuesday May 01, 2001 @05:45AM (#255085)
    Using the -W1 is marked as DANGEROUS in the documentation for a reason.

    Anyone who enables this setting on a machine will eventually be haunted by Mr. Clusterfuck.

  • by Anonymous Coward on Monday April 30, 2001 @02:26PM (#255086)
    To utilize the higher Ultra DMA speeds of your drive you need two things.

    First, and most importantly you need an IDE controller that supports UDMA66. Your 486 won't have this onboard. You'll need to get a new controller card. If you have a newer Pentium clas machine, then you may already have it onboard.

    The second thing you need is the right driver. You need to get the latest UDMA66 capable driver for you IDE controller.

    Have fun, and after your all done... Betcha can't tell the difference.

  • Pretty easy when you think about it.

    A faster clock means the host adapter can more efficiently switch amongst devices, servicing those devices with pending data quicker (and, if they've been waiting for long, chances are it'll be in their cache.)

    - A.P.


    --
    Forget Napster. Why not really break the law?

  • Sure, maybe a single drive... but if you've got 5 or 6 of those 15K RPM Seagate bastards on a single chain, you'll easily max out Ultra 80, but you'll still have a little headroom on an Ultra 160 chain. Sure, no drive can actually do 160MB/second ALONE, but a bunch of them sure can.

    - A.P.

    --
    Forget Napster. Why not really break the law?

  • You're close -- The extra wires are there to provide more "bleed off" speed for the cable. With a 40-wire cable. there's like one or two ground wires, but with 80-conductor cables every data conductor will have a coresponding ground conductor.

    In DMA-66 and DMA-100, this allows each data line to be used again quicker, because the previous signal 'bleeds off' quicker due to paired ground lines, whereas DMA-33 and slower have to wait for the shared few ground wires to bleed the signal off.
    .
  • Not everything is backwards compatible. I recently ran into a problem when trying to install an IBM 10GB IDE drive on a Tyan Tomcat IV motherboard. It turned out that the IDE implementation (Intel PIIX3) on the motherboard was incompatible with the IDE implementation on the hard drive. The IBM drive works fine on newer motherboards.
  • Windows: I don't believe DMA is enabled by default on windows(both for Hard drives & CD/DVD), but there is a setting in the device manager of the control panel.

    W2K enables DMA on harddrives by default, but not on CD/DVD units. I don't know about 95/98/ME/NT4 though.
  • by keepper ( 24317 ) on Monday April 30, 2001 @10:29PM (#255092) Homepage

    IDE RAID performance is GREATLY improved by having all drives sit in their own channel.

    Also, if you were looking for best perfomance, and reliability, Raid 10 is the way to go. For a small array, raid 5 is not much of a performance boost over a single drive. ( parity calcs )

    Also, those 3ware raid cards rule under FreeBSD, and are not too expensive.. :) ( ~$250 4 channel )
  • I trashed my filesystem but good using this. Essentially, -k1 (the default is -k0) will keep your hdparm settings, should the IDE controller issue a reset for some reason. Why would it do this? Under normal opperation I don't know, but I did manage to hand hdparm a -Xnn that my hardware did not like. Since the controller didn't like what I had done, it tried to issue a reset, to undo my mistake (the bad -Xnn). Unfortunately, I had also issued a -k1, which forced the bad -Xnn setting to be restored, which pissed off the controller, which reset, which.... well, it was a big ugly loop. By the time I stopped it, it had pretty much hosed my filesystem.
    Bottom line: make sure your hdparm settings work before issuing the -k1!
  • by ScottG ( 30650 ) on Monday April 30, 2001 @04:06PM (#255094)
    A good write up about using hdparm to improve hd performance and the risks involved can be found here:

    http://www.oreillynet.com/pub/a/linux/2000/06/29/h dparm.html [oreillynet.com]

    ...including some discussion of what those DMA modes are and their merits.

  • by dead_penguin ( 31325 ) on Monday April 30, 2001 @09:59PM (#255095)
    hdparm can be a great little utility for speeding up your system-- if used carefully! Before doing *anything* with it (other than simple benchmarking), make sure you have backups of all your data. Putting a drive/controller combination into a mode they don't support can completely mess up your system. Believe me, I've done it twice already, and even with backups it's still a huge pain in the ass to reinstall.
  • Wrong. It's more accurately called ATA/ATAPI-4 for the 33MB/S interface, ATA/ATAPI-5 for the 66MB/S interface, and ATA/ATAPI-6 for the upcoming 100MB/S interface (note that the 100MB/S standard has not been released yet, and all these 100MB/S drives you see now are jumping the gun a bit.
  • by ASCIIMan ( 47627 ) on Tuesday May 01, 2001 @11:44AM (#255097)
    Neither is correct. The only "correct" name for the interface is ATA/ATAPI, unless you're referring to ATA-1, ATA-2, or ATA-3, which had maximum transfer rates of (respectively) 8.3MB/s, 16.7MB/s, and 16.7MB/s. Ultra DMA and ATAPI arrived in the same standard, ATA/ATAPI-4 (technically, the ATAPI standard was released before this, but this is when it officially joined itself with the ATA spec).

    Note that DMA modes determine the mode of data transfers across the interface, and thus also determine the rate of transfer. Since ATA specs are backwards compatible with all DMA and Ultra DMA modes, and often include more than one additional DMA or Ultra DMA modes (for example, the ATA/ATAPI-5 standard included both the well-known 66.7MB/s Ultra DMA 4 standard, it also included the almost never heard of Ultra DMA 3 standard, which runs at 44.1MB/s; also note that the ATA/ATAPI-4 standard included both the well-known Ultra DMA 3 at 33.3MB/s, but also the lesser-known Utlra DMA 2 at 25.0MB/s) thus, when refering to the speed of the interface (and not the additional features included in that version of the ATA/ATAPI spec), it would be more correct to refer to "DMA" or "Ultra DMA" than "ATA".

  • by z4ce ( 67861 ) on Monday April 30, 2001 @04:29PM (#255098)
    I almost forgot the -c1 option! That's one of the best options actually... it turns on 32-bit data-transfers... provides quite a nice performance increase.

    Ian
  • by z4ce ( 67861 ) on Monday April 30, 2001 @04:24PM (#255099)
    Can all be changed with hdparm. I use
    hdparm -W1 -m16 -u1 -c1 -k1 -d1 /dev/hda
    on start up.
    That is...
    -W1 enable the write caching feature
    -m16 allow 16 blocks per i/o interrupt

    -u1 IRQ unmasking.. HUGE proformance increase. If you notice everything seems to stop when your doing a lot of I/O be sure to turn this on!

    -k1 keep settings.

    -d1 enable DMA

    From my simple benchmarks/experience these seem to be fastest settings for my IBM DeskStar 14gb HD. Your mileage may vary.

    Ian
  • Well, yeah, but my point is that refering to ATA as "DMA" is not entirely correct.

    ----
  • Because there's probably one particular model of Widgetcorp hard drives that don't support it correctly, so for compatibility reasons its disabled by default. Actually, I know if Windows, enabling DMA on a CDR/CDRW drive is begging for lock-ups and general wierdo behaviour - but DMA is almost necessary to use a DVD drive...

    ----
  • I think he meant PCI speed, which on most boards is limited to 133 MB/s (32 bits X 33 mhz). Of course, newer Macs have 266 MB/s (64 bits X 33 mhz), and high end server boards have 533 MB/s (64 bits X 66 mhz). Coming soon, fun interfaces like Infiniband, PCI-X, and LDT/HyperTransport, where life starts at around 1GB/s....

    ----
  • by levendis ( 67993 ) on Tuesday May 01, 2001 @03:59AM (#255103) Homepage
    Technically, DMA just means Direct Memory Access, and just about any peripheral that uses large amounts of data (SCSI card, network cards, etc) is using DMA these days (hopefully). DMA is just a way of moving data from the card to the host computer's memory with little CPU intervention, i.e. instead of copying data bit-by-bit from your IDE controller, the driver just says "copy block 1152 into memory location 853E4210" and the hardware takes care of the actual data movement.
    So the UltraDMA stuff you are asking about is more accurately called UltraATA. ITs basically an extension of the ancient AT disk interface spec to encompass new features like DMA, auto-detection, higher raw data rates, removable media, etc. (I think UltraATA even supports some SCSI-like features such as disconnect)

    ----
  • I still tend to buy only SCSI disks. They cost more, but tend to have better specifications, in general.

    The manufacturers figure that people buying SCSI disks are probably building RAID arrays. There the high bus bandwidths actually help, unlike a typical desktop installation.

    My desktop machine is fully U160, meaning a potential buss throughput of 160 MB/s. dd if=/dev/da0s1 bs=10m of=/dev/null count=64 shows a throughput of about 35 MB/s. So I could have 4 disks running flat out and the disks would still be the bottleneck. Never mind that we're not doing any seeking with that command. It's more likely that you would expect to see upwards of 8 drives or so before buss bandwidth starts to be an issue.

    Oh, remember that typical motherboard memory bandwidth tops out below 160 MB/s too, so those transfer rates really only count when you're using a RAID controller (as opposed to software RAID).

    Kirk McKusick spoke briefly at FreeBSDCon '99 about his experiments with IDE/ATA and SCSI. His results (as expressed on the videotape) may not be fully up-to-date (I don't think he used UDMA66). But he was able to demonstrate that more than one target per bus on ATA did particularly poorly compared to SCSI.

    Oh, also... Make sure you turn write caching OFF if you expect your data to survive a power failure. FreeBSD 4.mumble turns it off by default and 4.3 now makes it configurable. Kirk also mentioned that people were telling him that "small file tests" showed that ATA was on a par with SCSI. He found that this was due to write caching (that is, the drive lies about when the data has been written). To use his words, "wrong answers can be delivered quickly."
  • scsi is arbitrated and parallel, so no matter how many devices you have on it, no more than one at a time can communicate over the bus. Ultra 160 helps this how?
  • yeah, duh. i thought about that after i posted my amazing witticism. guess i need to smoke a little more crack before i post :/
  • The above article was very helpful. Someone mod this guy up!

    How did I not know this? And I call myself a Linux admin? =)
  • by green pizza ( 159161 ) on Monday April 30, 2001 @02:46PM (#255109) Homepage
    DMA is direct memory access, that is, an operation that will bypass the CPU for better performance.

    To enable DMA for a hard drive:
    hdparm -d1 /dev/hda

    To disable DMA for a hard drive:
    hdparm -d0 /dev/hda

    To enable Ultra-DMA/66:
    hdparm -X66 /dev/hda

    To measure the transfer rate of a hard drive:
    hdparm -Tt /dev/hda

    To see what options are enabled for a hard drive:
    hdparm /dev/hda

    To see many details about your drive:
    hdparm -i /dev/hda

    I have an onboard ATA/33 IDE controller and a hard drive that supports ATA/66, so obviously I cannot use ATA/66. But by using stock ATA/33 and turning DMA on, I was able to get about a 30% boost in performance when tested by hdparm. I only know the basics and a lot of is still cloudy and/or seems to be voodoo magic. Could someone please explain this better for me as well? Also, should the above commands be entersted into an RC startup script?

  • It seems that DMA isn't found on installation and isn't started by default. If your drive supports it then why isn't it automatically configured and started at boot time? Just curious?
  • Ah, sex is a topic slashdot readers probably couldn't help out with ;-)
  • you forgot the 80 pin cable.

    it isn't an 80 pin cable, it's an 80 wire cable...with 40 pins, just like a regular IDE cable. the extra wires are for shielding. you'll get one in the box with any newish motherboard or UltraATA/66 or UltraATA/100 controller card.

  • by krismon ( 205376 ) on Monday April 30, 2001 @05:36PM (#255113)
    It's getting to be pretty standard, UDMA, which is fancy for faster Direct Memory Access. You would need the hardware for it... most new machines have UDMA/66 built in, some older ones have UDMA/33, and the newest of the new have UDMA/100, these are the speeds that the controller will (theoretically) transfer data at. You'll also need Hard drives that support the protocols... it should also be noted that things are backward compatible... you can run a UDMA/100 capable drive on a 66 controller, but it will run at 66. and you can run a udma/66 drive on a 100 controller but it will run at 66 (will always run at the slower speed, doh!).

    If you have an older machine... There are add-on PCI IDE controller cards that support UDMA 66 or 100, they are pretty reasonable at under $50 (100) and some cheaper 66 versions can be had for under $25.

    I have setup a FreeBSD fileserver with 4 60GB maxtor udma/100 drives and a promise udma/100 controller running vinum(freebsd version of lvm) with a raid 5, pretty easy to do, but not the fastest thing in the world.

    Windows: I don't believe DMA is enabled by default on windows(both for Hard drives & CD/DVD), but there is a setting in the device manager of the control panel.

    Linux: hdparm, man hdparm.

    Mac: I believe the G4's have UDMA/66 built in.

    Also note that the cable is different... you can't use the old IDE cable to run in UDMA mode. most controllers come with (80 pin?) cables. And jumper settings on the drives alone don't determine master/slave, The cable will determine this also.. they will be labeled master & slave as well as be color coded(on good cables).

    That's about all I know. ;)
  • by gus goose ( 306978 ) on Monday April 30, 2001 @03:51PM (#255114) Journal
    Whu get thousands of answers from others when you could have used Google [google.com]?
  • by Zeio ( 325157 ) on Monday April 30, 2001 @07:17PM (#255115)

    I have noticed in the recent past that there has been a lot of marketing whoring with regards to Ultra DMA and its various speeds.

    I am most disappointed with IDE in general from a performance standpoint. I go through hardware all the time because of the nature of my job, and two things stick out as the sore thumb in bad system performance. The first is the availability of huge quantities of memory, the second being the hard drive.

    As far as controllers go in the this area of performance, I tend not to care for anything that is not Intel or Promise, not that I have a fetish for Intel goods. I've yet to try any striping/parity striping controllers yet either. My observation of IDE thus far, regardless of bus 'speed' is somewhat negative. High CPU usage, bad multi-thrashability (e.g., hitting the disk with nasty requests in multiple ways all at once). I feel the hard disk holding me up, especially in Windows. I have found the following registry keys for Windows 2000 to enable DMA66+ operations, FYI:

    From this site [aol.com]...

    To activate the ATA/66 (UDMA/66) setting, you need to run Regedit (or Regedt32) and go to:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\000 0

    If using Regedt32 uncheck "Read Only Mode" in the Options menu. Note that the "0000" key above might show as "0001", "0002" or "0003" on your machine, depending on your particular hardware settings. Select the key appropriate to your case. Right-click to create a new DWORD [REG_DWORD] Value, call it "EnableUDMA66" (no quotes), and type 1 in the Decimal box to enable ATA/66 (UDMA/66) support. To disable it, change the Decimal value to 0, or delete the "EnableUDMA66" Value altogether. Reboot when done.

    A MUST: To properly enable the UDMA/66 setting, you need to have your ATA/66 (or ATA/100) capable drive(s) hooked up to a different IDE channel than the one your older (E)IDE (even if UDMA/33 capable) drive(s) are connected to!

    Another site has directions for NT 4.0 Sp5+ here. [arstechnica.com]

    Another useful site is here, BMDRIVERS [bmdrivers.com].

    Here and there you will see reports about reduced CPU usage. This is laughable. One place indicates that mass transfers were taking 90% CPU and with the new and improved drivers, a "mere 56%". Meanwhile all my SCSI drives never elevate the CPU at all.

    Another alternative to using all these tweaks and hacks is to just download the Intel drivers [intel.com] (if you have an Intel chipset which you should for PCs, save the glorious Athlon).

    I have noticed various anomalies with these drivers.

    Sorry for giving so much attention to Windows, these operating systems tend to need the most attention. As far as unix goes, the hdparm suggestions I have seen so far seem correct, thanks for the input.

    The SCSI paradigm is greatly suffering from the same pomp with festering numbers. My experience has been that Ultra 160 drives perform no better than Ultra 80. Open Magazine did a whole battery of benchmarks to illustrate its uselessness (unable to locate link).

    I personally look for fast rotational speed, good platter density and fewer platters and a fast media rate, and lastly seek times.

    IDE and its Ultra friends are great for huge drives to dump crap onto, and even mirror. Keep the OS and the swap file on a SCSI drive, and you can use your CPU for something else.

  • I realize that i'm being a nitpicky bastard for doing this but i feel maybe it will clarify this little thing that's been bugging me for people who may not be familiar with this kind of thing.(how's that for a run-on sentence, eh?) Linux is an operating system (duh). Macs and PC's are not operating systems. Linux can RUN on both macs and PC's. Therefore it would be more appropiate to compare linux to MacOS or Windows. Otherwise you're basically comparing ketchup to hot dogs.

It is easier to write an incorrect program than understand a correct one.

Working...