Have i tried everything to improve my disk performance?
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
hdparm -c: zero effect when using_dma=1
Submitted by Mark Lord (not verified) on Thu, 2005-05-26 09:44.
Hi, I wrote hdparm, and I wrote the Linux IDE Disk drivers. So I know how these things work.
"hdparm -c1" has ZERO effect when using DMA. None, nadda, nothing at all. The two code paths do NOT intersect within the kernel at all.
Oh, ditto (as per my comment above) for "-m". Multisector mode (-m) applies only when NOT using DMA. Fiddling the setting while DMA is active has ZERO effect. None, nadda, not a shred of difference.
Hmmmm you could set an higher readahead, it might help during big transferts ( hdparm -a 16384 ).
Also, you could set an higher DMA transfert mode (WARNING, BIG FAT WARNING : IT IS DANGEROUS, NOT RECOMMENDED AND EVIL! This might cause corruption, instability and various evilness, consider yourself warned), as your disk reports it is not using the best possible mode ( NB : there is probably a reason why it uses a slower mode, maybe you Mobo controller don't support any better!!!). In case you want to try (fool!) the command is : (hdparm -X udma3 ). Your drive reports to support from udma1 to udma5, but I suggest that you increase this step by step.
I doubt you will be able to get better than 15MB/sec with that drive...
It is possible that your motherboard don't support anything better than 20GB (no clue, but it seems strange to me... 20 GB is very small, at my opinion, you are safe if you don't go above ~120GB), however sometime a bios upgrade can fix this.
In the worst case, Linux will be able to see the drive (and that's for sure!) BUT if your Bios don't support the new drive, you will not be able to set DMA on it, so you will have horrible performance.
Thanks for the clues. I have a feeling that the mobo only supports udma 2, so I think I might give your evil ;-) advice on the dma settings a miss. cluck cluck. I'm a chicken.
Will have a go with the read-ahead setting.
I read somewhere that there are two types of IDE cable (40/80 somethings). is it possible that i have the wrong cable? and if so, how would I know?
I don't know the specs for your board but, the 80 wire IDE cables were introduced along with the ultra dma modes your hard drive is reporting. If i remember correctly a 80 wire cable is needed to run on udma modes above 2. The newer cables still have 40 pins so i guess they should work with older boards too, you just won't see any performance boost. I'm pretty sure the 80s let the board run the IDE at 133Mhz as well.
I read somewhere that there are two types of IDE cable (40/80 somethings). is it possible that i have the wrong cable? and if so, how would I know?
Well, if you have old 40 pins cable, it will hurt preformance, however I really doubt that you do have some cable, unless you salvaged an old Pentium1 to build this computer. 40 pins cable aren't very common these days, you won't get anything at stores but 80 pins cables.
I read somewhere that there are two types of IDE cable (40/80 somethings). is it possible that i have the wrong cable? and if so, how would I know?
The 80 wire IDE cables were created to address the problem of crosstalk between the data lines in the 40 wire cables. The 80 wire cables still only have 40 data lines. The difference is that on the 80 wire cables there is a ground wire between each pair of data wires. That prevents the electrical activity of any given wire from creating a false signal/noise on its neighbors through capacitative coupling. The 80 wire cables can be used on any IDE 40 pin connector. The benefits of the extra ground wires will help older IDE drives to some extent. It certainly won't hurt anything.
For the drive size it should accept 32gb or that is what I had to jumper my drive at in my old BX board then when installing linux will see the extra capacity and allow you to use it or at least it did with my 40gb that I used in the machine. For the DMA you are probably getting all that you will from it my board was limited to DMA33 some BXs you can get support DMA66 but you will not get one supporting DMA100 unless you put in a separate controller card.
I guess I probably have 80 pin cables already, as I built this rig from a 2002AD vintage computer (pentium III, 440BX). If memory serves, I bought new IDE cables anyway a year ago when I thought a faulty cable was causing my HDD problem (it was the drive, hence the current cheap n slow replacement).
Still, I'm very happy ab the speed increase to >18MB/s. I will now have to work out how to make the change permenant - unless someone on this forum feels like making my life easy and just telling me.
Distribution: RH 6.2, Gen2, Knoppix,arch, bodhi, studio, suse, mint
Posts: 3,304
Rep:
hdparm isn't a good benchmark for overall performance. making the readahead that high will hurt random disk access. making your readahead 2 megs max out your hdparm results.
adding a line to your startup scripts such as
hdparm -a 2048 /dev/hda
will do what you want.
I think that this readahead works only when reading bigger files. Did you see that your applications are working faster?
I'll try setting this to 2mb too.
Still, I'm very happy ab the speed increase to >18MB/s. I will now have to work out how to make the change permenant - unless someone on this forum feels like making my life easy and just telling me.
viva linuxquestions - excellent help. thank you.
Ben
Edit the file /etc/hdparm.conf and use the options/examples in there to enable the mode(s) you want at startup.
Distribution: RH 6.2, Gen2, Knoppix,arch, bodhi, studio, suse, mint
Posts: 3,304
Rep:
i think when i was deciding what hard drive parameters to use, I made a script, something like
dd if=/dev/zero of=/tmp/2gigfile bs=1024 count=2000
for i in 128 256 512 1024 2048 4096; do
hdparm -a$i /dev/hda
time tar clf - /opt > /tmp/opt.tar
time cp /tmp/2gigfile /tmp/2gigfile.copy
done
rm /tmp/2gigfile /tmp/2gigfile.copy /tmp/opt.tar
if you have 4 gigs of ram, this is a useless test. anyway, you can probably see the differences that the settings make with big and small files. if your opt dir is smaller than a gig, pick something else.
Again - without wishing to kiss too much a** can I say thanks again for all the helpful replies.
Here's the output from the script - i don't know how to interpret , I'm afraid:
Code:
ben@nutmeg:~/scripts$ sudo ./testHD
2000+0 records in
2000+0 records out
2048000 bytes transferred in 0.057679 seconds (35506890 bytes/sec)
/dev/hda:
setting fs readahead to 128
readahead = 128 (on)
readahead speed 128
tar: Removing leading `/' from member names
real 0m0.064s
user 0m0.006s
sys 0m0.020s
real 0m0.085s
user 0m0.003s
sys 0m0.045s
/dev/hda:
setting fs readahead to 256
readahead = 256 (on)
readahead speed 256
tar: Removing leading `/' from member names
real 0m0.063s
user 0m0.006s
sys 0m0.018s
real 0m0.086s
user 0m0.002s
sys 0m0.045s
/dev/hda:
setting fs readahead to 512
readahead = 512 (on)
readahead speed 512
tar: Removing leading `/' from member names
real 0m0.061s
user 0m0.006s
sys 0m0.017s
real 0m0.084s
user 0m0.004s
sys 0m0.043s
/dev/hda:
setting fs readahead to 1024
readahead = 1024 (on)
readahead speed 1024
tar: Removing leading `/' from member names
real 0m0.063s
user 0m0.008s
sys 0m0.017s
real 0m0.085s
user 0m0.003s
sys 0m0.044s
/dev/hda:
setting fs readahead to 2048
readahead = 2048 (on)
readahead speed 2048
tar: Removing leading `/' from member names
real 0m0.063s
user 0m0.008s
sys 0m0.015s
real 0m0.086s
user 0m0.006s
sys 0m0.042s
/dev/hda:
setting fs readahead to 4096
readahead = 4096 (on)
readahead speed 4096
tar: Removing leading `/' from member names
real 0m0.062s
user 0m0.006s
sys 0m0.017s
real 0m0.085s
user 0m0.004s
sys 0m0.043s
There are two factors of a hard drive. One is throughput. The other is accessing time. For Linux, any hard drive with the lowest accessing time will be better. Since your hard drive has close to 13 milliseconds, no wonder it is slow.
By using Linux, the capacity limit of the BIOS is irrelvant. If the kernel has large block support enabled, Linux can provide a few terabyte limit capacity even though the BIOS has a 32 GB limit. However the first partition have to be within limits of the BIOS limit capacity which should be hard because usually /boot is there.
The results say using readahead of 512 will give you a little bit of performance.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
in a new disk is there anything else I can try, or am I stuck with a slowish disk?
, I'm afraid:
