| View previous topic :: View next topic |
| Author |
Message |
Kartoffel
n00b
Joined: 23 Apr 2002
Posts: 29
|
 Posted: Tue Apr 30, 2002 3:40 pm Post subject: System slowdowns during heavy HD access |
 |
|
hi all. I've got gentoo installed on a new system I built. it is an amd 2000+ 512 mb ram 1024mb swap, wd120GB w/ 8mb cache, soyo dragon plus mobo.
When I run X and I am compiling in an xterm the system slows down to a crawl. I notice because the mouse is irresponsive for a couple seconds. At first I thought it was a mouse problem but also text typed into an xterm doesn't show up for a couple seconds.
The best I can figure is something is wrong with my hard drive setup. I have basically a stock gentoo setup I never changed much that wasn't in the install or desktop config guide. Especially nothing that has to do with hard drives. When I compiled the kernel I chose "Use DMA access when available" I also enabled promise controller because I think my motherboard has that controller and I didn't think it would hurt anything. My hard drive shows up as hda. I have a raid controller on the mobo but it is disabled in bios and i'm not using it or the extra ide slots it provides.
The only other thing I notice is during kernel boot there is a message that flashes by saying ide bus speed 33 MHz overide with ide=xx or something similar but I don't know what this means. I've ignored it on other systems that work fine. But if this is an important fix please tell me where to fix it.
I've tried to provide all the relevant info but I'm sure I forgot something. Let me know and I'll fill in the gaps.
Thanks.
Jeff |
|
| Back to top |
|
 |
Xafloc
n00b
Joined: 19 Apr 2002
Posts: 48
Location: Wisconsin
|
| Posted: Tue Apr 30, 2002 6:10 pm Post subject: Ditto... |
|
|
I experience the same thing, although my system is not af "beefy" as yours. 40G 7200 RPM Drive, 256 PC2100, AMD XP1600.
Let me know if you find a way to increase performance.
Perhaps, tweaking with hdparm is the solution??
_________________
Darren Greer
http://www.nod.to
http://www.alinuxbox.com |
|
| Back to top |
|
|
CaptainCaveman
n00b
Joined: 23 Apr 2002
Posts: 23
|
| Posted: Tue Apr 30, 2002 6:45 pm Post subject: |
|
|
"When I run X and I am compiling in an xterm the system slows down to a crawl."
I've experienced things like this, and I always just chalk it up to the fact that I'm compiling in the background, and compiling isn't exactly notorious for being light on the processor. |
|
| Back to top |
|
|
Kartoffel
n00b
Joined: 23 Apr 2002
Posts: 29
|
| Posted: Tue Apr 30, 2002 7:10 pm Post subject: |
|
|
caveman;
I wouldn't complain except I've used gentoo on my wive's 500 mhz with 128 meg ram and I've never had any slowdowns. when compiling and using X.
Jeff |
|
| Back to top |
|
|
Jeevz
Bodhisattva
Joined: 15 Apr 2002
Posts: 195
Location: Boston, MA
|
| Posted: Tue Apr 30, 2002 7:43 pm Post subject: |
|
|
| For concerns about hard drive performance you can check out this thread. |
|
| Back to top |
|
|
dyoung
n00b
Joined: 18 Apr 2002
Posts: 7
|
| Posted: Tue Apr 30, 2002 10:11 pm Post subject: |
|
|
I had a similar problem that was driving me crazy. If I was writing lots of small files to the disk (a 7200RPM Maxtor Fireball UDMA 100), the mouse and any animation on the screen would freeze, then unpause a second later, then freeze again.
I believe I tracked it down to a motherboard setting. I had foolishly overclocked my front side bus to 133MHz (I have a K7T266 Pro 2 mother board and Athlon XP 1700+). I never had a problem with it before but it definitely cause problems with this drive. I had similar issues under Windows 98.
Setting the front side bus speed back to the default seems to have cleared up the problem!
-- derek |
|
| Back to top |
|
|
squanto
Guru
Joined: 20 Apr 2002
Posts: 524
Location: Rochester, NY, USA
|
| Posted: Tue Apr 30, 2002 10:43 pm Post subject: |
|
|
You guys are probably all experiencing disk transfers with PIO mode on, rather than DMA. Run /sbin/hdparm -d /dev/hda *insert your drive there* (as root) and see if DMA is on.
# /sbin/hdparm -d /dev/hda
/dev/hda:
using_dma = 1 (on)
output like that if it is on. If it isn't on, look in your kernel config and find the correct ide driver for your system and include that, recompile your kernel and then see what happens.
I run ADM 1600+ with 512 of ram and 60gig 5400 drive, and have no slowdowns even when compiling, the only thing, is that apps take slightly longer, and by slightly I mean like 2 seconds for mozilla longer, to launch. There should be very little slow down for a system running an AMD XP processor even when compiling.
-Andrew |
|
| Back to top |
|
|
dyoung
n00b
Joined: 18 Apr 2002
Posts: 7
|
| Posted: Wed May 01, 2002 2:29 am Post subject: |
|
|
I take back my previous post about overclocking the front side bus causing the problem. My system still appears to grind to a halt with the mouse stuttering across the screen when doing an emerge.
Has anyone else seen this problem and know the cause? I have two drives that both use DMA:
/dev/hda:
Model=Maxtor 91707U5, FwRev=RA530JN0, SerialNo=H502S34C
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=33355728
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive Supports : ATA/ATAPI-4 T13 1153D revision 17 : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5
/dev/hdb:
Model=QUANTUM FIREBALLP AS60.0, FwRev=A1Y.1500, SerialNo=796118607613
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
BuffType=DualPortCache, BuffSize=1902kB, MaxMultSect=16, MultSect=off
CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=117266688
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 |
|
| Back to top |
|
|
Guest
|
| Posted: Wed May 01, 2002 2:38 am Post subject: |
|
|
| dyoung wrote: | I believe I tracked it down to a motherboard setting. I had foolishly overclocked my front side bus to 133MHz (I have a K7T266 Pro 2 mother board and Athlon XP 1700+).
-- derek |
133 Mhz is the default FSB setting for and Athlon XP 1700+ sir. |
|
| Back to top |
|
|
Malakin
Veteran
Joined: 14 Apr 2002
Posts: 1692
Location: Victoria BC Canada
|
| Posted: Wed May 01, 2002 3:06 am Post subject: |
|
|
Stuttering on my system got much better after I went from the gentoo kernel to 2.4.19-pre7 with the preempt patch. I'm not sure if the preempt patch is making the difference or just the different kernel, I think it might just be the kernel.
I am using dma. (XP1800, 512M DDR, KT333) |
|
| Back to top |
|
|
Coogee
Apprentice
Joined: 23 Apr 2002
Posts: 184
Location: E.U.
|
| Posted: Wed May 01, 2002 11:20 am Post subject: |
|
|
Kernel versions older than 2.4.19-pre7 do not recognize the VIA KT266A and KT333 chip sets and therefore only PIO access is working. If you check the boot messages (/bin/dmesg) you will find something like "VIA chipset not recognized".
With kernel 2.4.19-pre7 (in gentoo-sources-2.4.19-r1) DMA access is possible.
Another hint: Because the low-latency patch is also applied to 2.4.19-r1, one should not use hdparm for optimization (check out "Don't do that" on http://www.zip.com.au/~akpm/linux/schedlat.html). I appended "ide0=autotune ide1=autotune" to the kernel parameters (via grub or lilo) and everything works just fine. You can check if DMA is working with "hdparm /dev/hda" (in this case hdparm is only used to get information). |
|
| Back to top |
|
|
squanto
Guru
Joined: 20 Apr 2002
Posts: 524
Location: Rochester, NY, USA
|
| Posted: Wed May 01, 2002 2:19 pm Post subject: for 2.4.17 and 2.4.18 |
|
|
for kernels 2.4.17 and 2.4.18 you can patch with hedrick's ide patch to get via 266 chips to work with DMA as well, not only the -r patches, but I do believe that most recent -r patches also include hedrick's patch.
I run 2.4.19-r1 with my via kt266a epox board no prob, I get 28 meg/sec on my drive. |
|
| Back to top |
|
|
Kartoffel
n00b
Joined: 23 Apr 2002
Posts: 29
|
| Posted: Wed May 01, 2002 3:44 pm Post subject: |
|
|
/sbin/hdparm -d /dev/hda
said I didn't have dma on. So 5-6 kernel compiles later I found the right ide controller and now that works.
Of course this morning I compiled the new gentoo sources so I don't know if there is another improvement there. I'll check it out.
As a side question does gentoo-sources-2.4.19-r1 actually include all patches up to 2.4.19-pre7? I've been having problems with other drivers and I've never gotten a straight answer on exactly what kernel version I was using.
Thanks for the help.
Jeff |
|
| Back to top |
|
|
Coogee
Apprentice
Joined: 23 Apr 2002
Posts: 184
Location: E.U.
|
| Posted: Wed May 01, 2002 4:06 pm Post subject: |
|
|
You can find out what is included in kernel sources by viewing the ebuild-script.
gentoo-sources-2.4.19-r1.ebuild:
# INCLUDED:
# 2.4.19-pre7-ac2
# grsecurity-1.9.4 (with fixes and a fix for an NVIDIA driver compile problem)
# 2.4.19-pre7-low-latency
# htb2 (QoS support)
# preempt-kernel-rml-2.4.19-pre7-ac2-1.patch
# preempt-stats-rml-2.4.19-pre5-ac3-1.patch
# 1000 HZ patch
# from jp10 (http://www.infolinux.de/jp10):
# 41_twofish-2.4.3.bz2
# 50_crypto-patch-int-2.4.18.1.bz2
# 50_crypto-patch-int-2.4.18.1-1.bz2
# 51_loop-jari-2.4.16.0.bz2
# 90_freeswan-1.97.bz2
# from aa:
# 00_3.5G-address-space-4 (from Andrea Archangeli) |
|
| Back to top |
|
|
Guest
|
| Posted: Thu May 02, 2002 2:51 pm Post subject: |
|
|
You should also read the previous disk/hdparm forum thread about various options and their impact on performance (https://forums.gentoo.org/viewtopic.php?t=51)
The responsiveness and overall feel can be improved if you unmask the IRQ, i.e. free the computer to acknowledge other interrupts while it's handling the IDE commands/interrupt. See option "-u 1" for hdparm.
I also noticed from the output from the Maxtor and Quantum drives that multiple sector mode wasn't enabled ("MaxMultSect=16, MultSect=off "). Enabling this ("-m 16") should also improve your performance. |
|
| Back to top |
|
|
mvo
n00b
Joined: 16 Apr 2002
Posts: 49
Location: Frankfurt/Germany
|
| Posted: Thu May 02, 2002 3:06 pm Post subject: |
|
|
Hi,
I have turned on DMA with my K7T266Pro and Kernel 2.4.18 with generic DMA driver and it works fine:
hdparm -d1 -c1 -k /dev/hda |
|
| Back to top |
|
|
Malakin
Veteran
Joined: 14 Apr 2002
Posts: 1692
Location: Victoria BC Canada
|
| Posted: Thu May 02, 2002 7:58 pm Post subject: |
|
|
| Quote: | | Another hint: Because the low-latency patch is also applied to 2.4.19-r1, one should not use hdparm for optimization (check out "Don't do that" on... |
I believe they're just saying that when you run hdparm it's using 50ms, it's only that once so it's not really an issue for most people.
I had dma working on 2.4.18 with a KT333 just fine, only had to edit a couple lines of kernel source.
I wish gentoo would give their kernel a new revision number everytime they change it, it's totally different then the last time I looked at it just recently and it's still called r1. It's looking much better now. |
|
| Back to top |
|
|
Guest
|
| Posted: Sat May 04, 2002 5:53 pm Post subject: Re: System slowdowns during heavy HD access |
|
|
| Kartoffel wrote: | | The only other thing I notice is during kernel boot there is a message that flashes by saying ide bus speed 33 MHz overide with ide=xx or something similar but I don't know what this means. |
The PCI bus (to which your IDE controller is connected) operates at a maximum speed of 33Mhz, with your PCI devices communicating synchronously, using 32-bit wide transfers for each clock cycle. So that gives a maximum transfer rate of 132Mb/sec (assuming no contention between multiple devices). The specification has been extended to support 64-bit transfers (using the longer slot type) at speeds of 66Mhz but this is not typical of a desktop class motherboard.
Now although 33Mhz is the official speed, many boards will allow overclocking of the PCI bus speed. For example, you might alter the ratio between your CPU_FSB/RAM/PCI clock speeds to maximize speeds and minimise latencies across these three primary buses. Fortunately, the majority of PCI cards seem to be quite happy at being overclocked.
However, this has been known to cause problems with regard to the timing cycles employed by the IDE protocol. IDE uses a simple mechanism where regular delays are introduced between attempts to continue I/O with a disk. The times are dependent on the PIO/DMA mode used by the disk and set by the chipset. If these delays are not within suitable tolerance levels your HD will throw a fit and strange and unpleasant consequences will ensue  !
The Linux IDE driver will accept an argument which will force it to assume a given clock speed - used in tuning the modes. So, if you increase the number it will actually slow the rate of I/O down to stay within specs. This also works in reverse, you can effectively "overclock" your IDE I/O speeds by lowering this number, and it has been done (particularly on older machines). Needless to say this is very dangerous indeed! Low latencies are great but only within the operational limits of every device affected, otherwise the timing goes out of the window. I guess this is an important point for PCI overclockers ... to ensure a reliable configuration, make sure this parameter is passed to the kernel with the real speed of the PCI bus. That way the disk and your system should (hopefully) remain stable with the added benefit of lower PCI bus latency overall. Of course, there's no guarantee all your PCI devices will be happy about the speed increase - and they will run hotter! 
What else? When it comes to hardware, I generally think the board's BIOS should generally be kept up to date and the options should be considered carefully, they can have a big effect. IRQ sharing and bus steering can lower performance. Some boards will allow you to assign the IRQ to prevent sharing, or otherwise influence the assignments (higher IRQs get higher priority). Use MTRR support in your kernel also to optimise the way memory address spaces are accessed by the CPU. ACPI is a whole new ball game too, consider trying the kernel with and without. With ACPI, it is not uncommon to see devices apparently sharing an interrupt but if I've got this right, they get routed through to many available virtual IRQs. I presume ACPI is a "good thing" but only if your BIOS and all your devices (and the OS kernel) are fully compliant. If you have an ISA bus and don't use it, turn the bridge device off in the BIOS if you can. And the pre-emptive kernel patch (by Robert Love) will increase responsitivity at the (slight) expense of overall throughput.
Sorry about the length! |
|
| Back to top |
|
|
474
l33t
Joined: 19 Apr 2002
Posts: 714
|
| Posted: Sat May 04, 2002 5:58 pm Post subject: That was me ... |
|
|
Oops, said so much that I must have lost my session there ...  |
|
| Back to top |
|
|
|
Kernel & Hardware
