I've been having this problem for a little while now and it has finally annoyed me to the point where I have to ask for some help to fix it. For some reason, when I do large file writes or reads the I/O itself seems to take a lot longer than it used to on other Linuxes i've tried and the system becomes a bit unresponsive. This happens whether I am writing to my serial ATA drive, reading from it, or writing to my USB backup drive. Additionally, I think this problem is also manifesting itself when I try to play video files. The HD video files that I have will sometimes lag for up to 10 or 15 seconds if I seek forward or backwards in the file in mplayer. For smaller videos the lag will range anywhere from as low as instantaneous (normal) up to 3 or 4 seconds before recovering. Also, I noticed that when I copy large (where "large" means > 100 MB or so) files and I am listening to music, the music will cut out/pause for a second or two at a time every few seconds until the file is transfered. Finally, the last bit of evidence that I noticed is when I dragged/dropped a large file from one place onto my desktop and the GNOME file transfer dialogue that popped up (which shows speed) said I was only copying ~3 or 4 MB / sec. As far as I remember, the write speeds should be a bit more than 10x that much. I'd say perhaps their measurement/estimate is wrong, but the file transfers seem to take a lot longer than they should, which lends credance to their estimate.

I'd SERIOUSLY appreciate any help you guys can provide. I know it isn't my hardware because it works ok under windows/other linuxes, and in all likelihood I probably configured something wrong because I am still new to gentoo. Thanks in advance!

-Zorak

The first place I look when there some odd system behavior is the system logs (Linux/BSD/the ilk are much more verbose when there's a problem). Try to exercise the issue then check the logs for errors/warnings/general comments of concern. This would include (especially) the dmesg kernel message buffer, /var/log/messages (usually mirrors dmesg pretty closely, but sometimes grabs info from other locations) as well as some possibly distro-specific logs (poke around /var/log/). This is how I figured out that a USB card I was using for my optical mouse on an old system was a problem (kernel messages noted that "pci resource SOME_PCI_ID locked up the PCI bus, Eeep, this is not good" or some such message).

Additionally, if you want to test hdd performance in a somewhat meaningful way, try

Let us know what you find

Yeah, actually Linux_0 was kind enough to get on aim and help me out with similar suggestions that you have posted here. So I installed hdparm and smartmontools and a couple of other things and when i ran hdparm -t /dev/[sh]d[acd] i got results back that my IDE drive was working normally (~40MB/sec) and that my two SATA drives were reading at ~4MB/sec. So, i figured it was probably a software problem (bad or misconfigured software) since the drives work fine under windows and ubuntu, so I booted up with an Ubuntu LiveCD. After installing hdparm under the live environment I got much more normal numbers for the IDE and 2 SATA drives (~40 ~65 ~65), so I verified that my drives should work normally under Linux (or at least ubuntu). My next step will be to go and boot up with the gentoo liveCD and see whether or not the drives work properly under that live environment. If they do, I will attempt to figure out which software they are loading for SATA and see if I can compile in support for it in my kernel. As a last resort, I will move to genkernel like Linux_0 suggests, but at this moment I feel like the solution should be close enough for me to grasp, making movement to genkernel unnecessary.

I haven't had time to do any troubleshooting since Monday evening when Linux_0 helped me out, but as soon as I get the chance i will continue and I will post the results here.

Thanks guys!

-Zorak

I do not recall that

[Klink] veeeeery interesting[/klink]

You'll have to let us know the results of the other livecd

So i went ahead and tried hdparm -t on my different disks under the Gentoo x86_64 live disk and surprisingly enough, i got the same results as I have when i boot into my Gentoo system. I wonder if this means that Gentoo has problems with my motherboard's SATA controller? If so, why? Ubuntu seemed to work just fine with it, and all the same software should be available across distros, and even if there were a time lag between one getting drivers that the other already has, I ran this machine with ubuntu for a YEAR just fine, so by now they ought to have the same drivers available in the gentoo repos? I thought that LiveCDs were all about detecting hardware to get up and running, so this is very puzzling indeed.

The only other difference I can think of here is maybe it has something to do with 64bit vs 32bit liveCDs? I admit this is a bit of a stretch, but aside from the fact that they are different distros, this is the only thing that comes to mind.

bmouring, if you would be so kind as to tell me what SATA drivers you are loading as modules and/or have compiled into your kernel, that might be a useful thing for me to know as i am pretty damn certain this is a problem due to me not configuring the kernel properly or leaving something out.

Thanks guys.

-Zorak

Hmmmm, don' think knowing my drivers would help you, but I would be interested to see what modules are being loaded by the ubuntu and gentoo livecd's to compare and contrast. But if you want to know anyway, I have the nvidia SATA support built in for my standard disks

(option CONFIG_SATA_NV, location

Device Drivers->
__Serial ATA(prod) and Parallel ATA (experimental) drivers->
____<*>NVIDIA SATA Support
)

and 3ware 9xxx SATA-RAID support built in for my 3ware escalade 9500s

(option CONFIG_SCSI_3W_9XXX location

Device Drivers->
__SCSI device support->
____SCSI low-level drivers->
______<*>3ware 9xxx SATA-RAID support
)

I guess I was just curious on the off-chance that perhaps you had the same motherboard as me I knew it was a really long shot, but also I figured if you had some sort of generic SATA options set that i'd forgotten that would give me a nudge in the right direction. Thanks

-Zorak

I'd say your best bet now is to compare/contrast the modules that are being loaded by the two livecds since there's a disparity there

Yeah that is what I was thinking I'd do this weekend. I think doing that will probably help me fix the problem as there is no reason for a distro not to support the same hardware that a different distro has supported for at least a year.

First of all I would like to say this:


Chaac ~ # hdparm -tT /dev/sda; hdparm -tT /dev/sdb; hdparm -tT /dev/sdc

/dev/sda:
Timing cached reads: 7958 MB in 2.00 seconds = 3982.17 MB/sec
Timing buffered disk reads: 184 MB in 3.00 seconds = 61.25 MB/sec

/dev/sdb:
Timing cached reads: 7204 MB in 2.00 seconds = 3604.26 MB/sec
Timing buffered disk reads: 178 MB in 3.02 seconds = 58.88 MB/sec

/dev/sdc:
Timing cached reads: 7514 MB in 2.00 seconds = 3760.63 MB/sec
Timing buffered disk reads: 128 MB in 3.00 seconds = 42.65 MB/sec


I think the results speak for themselves

I want to thank you guys for all your help and especially Linux_0 for helping me confirm that this was indeed a misconfigured driver by showing me the tools necessary to diagnose the problem and for actually coming on AIM just to help me out. I also want to thank the wonderful people at #gentoo who helped me figure out that in particular it was the old ATA driver in the ATA/... section of the menuconfig that was conflicting with my SATA drivers.

The solution ended up being that I just turned off the old drivers (I had both turned on) and then turn on ACHI mode in my BIOS for my SATA controller and then recompile the kernel and change grub and fstab to reflect the new partition names I admit that to a linux newbie this would all be incomprehensible, but if you know what each thing does, it makes sense I guess that shows that I have really learned quite a bit since i started messing with FC2 way back in '05.

Anyways, THANK YOU GUYS SO MUCH!

-Zorak

Good job!

Those numbers look good and are where they should be.