this seems extremely slow. of course, I was also in KDE and doing an "emerge evolution" command at the same time... will this affect the results? (I will do it again in console mode with no other running commands)

the "q" before each option tells hdparm not to spit out a bunch of messages you probably dont wanna see every time you boot up. local.start seems to be gentoo's equivalent of rc.local - a good place to tack on some tweaks at start-up.

"-u 1" will not improve your benchmarks but it will improve the overall responsiveness of the system since it unmasks other IRQs while processing the (IDE) command(s).

NOTE !!!
The "-u" and "-m" options *can* cause file system corruption so if you have an older system you should be a bit careful with these options. Kernels >= 2.4 usually fix this for these system if you enabled the "CMD-640" and "RZ1000" bug fixes when you compiled your kernel. Anyway, you should do these tweaks at the beginning of your installation, before you have compiled and configured everything (fast reinstall if things fail ...).

Remember that those are burst speeds, you'll never even come close to those numbers unless you're doing burst speed benchmarks (something hdparm doesn't).

If DMA is enabled for that particular disk hdparm should show that udma4 or udma5 is selected. ~25 MB/s in buffered reads looks pretty OK for a 5200 rpm disk, I'm getting ~35 MB/s with an Athlon 1333 + 7200 rpm disk (running in udma4 mode).

one last thing, mine is in udma2 modes, I don't get higher modes listed, but I assume that udma2 is ata33 ? and udma4 is ata100 ? if I do a hdparm -d1 -X100 is that wise? the manual says this is dangerous.. but I know my drive can do ata100 (hdparm even says that) and my motherboard can do too, so .. is -X100 wise?

Well ... There is some confusion regarding the ATA-X, UltraATA-XX and UDMA modes ... That is because we're mixing ATA specifications, protocols and DMA modes. The manufacturers didn't wait for a "real" specification so they invented their own versions instead ...

The manufacturers mixed bits from here and there (to impress the consumers - i.e. you and me) so we also have names like UDMA-66 and stuff like that. But if you look at the table above I think you can see what modes there are and their burst speed specification.

Ozy: udma4 is UltraATA-66. udma5 is UltraATA-100.

If you do a hdparm -I /dev/hda (uppercase 'I') you will get a more precise description of what your disk can handle. Compare that to the table above.

And yes, the -X option can be somewhat dangerous - don't do that on a system you've been working on for several days to install and configure

so my hd is in udma2 but can do udma5 (ata 100 .. the one I want) how do I get in udma5? hdparm -X100 /dev/hda ? or must I change something in my bios? and what if I mount my disks read only just to try it out? should that be saver ?? and what if I put my bios in read only and then try it could that garantee 0% data loss ? Or should I give my kernel the ide=100 (or whatever it was) to get to udma5? any idea's??

(Sorry for editing your post, but you posted it as a Guest, and I had no means to contact you first. And I think it's safer this way, just in case people don't read your update.)_________________| www.gentoo.org | www.tldp.org | www.google.com |

For anyone wondering if there's a difference between -X68 and -X69, I'm getting 40.25M/sec -t either way so it's not making any difference for me. As long as you're using -X68 I wouldn't bother trying to set it to a higher speed, unless maybe you're doing raid striping or something that would increase the throughput beyond that of a single drive.

This is on a kt333 and a maxtor 60G 7200, had to edit the kernel source so the south bridge was identified as a 8233 instead of the 8233a that it is since the 8233a is considered unknown in 2.4.19 kernel that emerge is giving me although I see now that according to the patch log on kernel.org it's apparently supported as of 2.4.19-pre5.

The space between the option and it's value doesn't matter, hdparm recognize both formats, even the hdparm author writes it sometimes as "-d 1" and at other times as "-d1". The man page synopsis shows it with spaces.

First: You wrote "/dev/hdc" is the disk *really* at that device id? You're not trying to enable dma on your cdrom, are you?

There are a couple of things that possibly prevents you from enabling DMA on your Deskstar disk.

- The kernel/hdparm has your specific disk on the "black list". A list of disks with known or reported problems.

- Your disk doesn't support DMA ... At least was not detected as a DMA capable drive. Try "hdparm -I /dev/hdc" and you'll get a list of the modes hdparm thinks your drive can handle.

- Chipset problem. Since you wrote "/dev/hdc", perhaps it's located on a HPT or Promise controller?

BTW, regarding -X 68 and -X 69, I don't exactly remember when the kernel and drivers started to support UltraATA-100 (udma5). If it's not supported by this kernel/driver version you will probably not gain anything even if you enable udma5 mode. That is perhaps what's happening, same thing as in Windows

Thanks to this thread I've found the source of a problem I've been trying to fix for some time now! I have a 100mbps switched network that was only giving me 33% usage when copying files form my windows machine to a fileserver running linux with 3 drives stripped. For a while I thought it might be the network cabling since they're all old and have been kinked...I checked out this thread and did some tests on my drives. Before tweaks, two of my three were showing reads of 100MB/s and writes between 10 and 11 MB/s. The second drive was down low in 3MB/s which tells me it was the limiting factor! I tweaked it up and it was getting 10-11MB/s also. After doing that, my network shows throughput of around 60Mbps steady and operations between 50 and 75 mbps!! WOOHOO