Have i tried everything to improve my disk performance?
I am running the following drive off my 440BX mobo.
Model Number:ST320014Athe system performance is a little bit lacklustre, so I started hunting for solutions. using hdparm -tT: /dev/hda:My disk info:
I've tried a variety of maneuvers including turning on dev/hda:With no improvement. Likewise running on init 1 (to exclude a gnome-effect) and running via KDE/knoppix CD. So - apart from investing some $:twocents: in a new disk is there anything else I can try, or am I stuck with a slowish disk? If it is a matter of a better HDD, I've been told that the 440BX can only accept up to 20GB drives. is this true? Ben PS. I found this interesting information on http://www.linuxjournal.com/article/8317 Quote:
|
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. I hope this help :) |
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? thanks again drben |
From 13.9 to 18.2 ain't bad!
Thanks ben@nutmeg:~$ sudo hdparm -a 16384 /dev/hda Password: /dev/hda: setting fs readahead to 16384 readahead = 16384 (on) ben@nutmeg:~$ sudo hdparm -tT /dev/hda /dev/hda: Timing cached reads: 540 MB in 2.00 seconds = 269.64 MB/sec Timing buffered disk reads: 56 MB in 3.08 seconds = 18.20 MB/sec |
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.
Have a look at this: http://www.mikeshardware.com/howtos/...ct_ide_hd.html |
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 just had to add my two cents. :)
Quote:
|
Quote:
|
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. :D viva linuxquestions - excellent help. thank you. Ben |
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. |
Quote:
|
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. |
output from whansard's script
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:study: , I'm afraid: Code:
ben@nutmeg:~/scripts$ sudo ./testHD |
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. |
All times are GMT -5. The time now is 06:40 PM. |