You are not logged in.
Pages: 1
Drive: EIDE WD1200JB 120GB 8mb cache (Western Digital)
When I used Gentoo last year I had problems with slow file copying because DMA wasn't enabled. In Arch it feels like the DMA is ok, but I've noticed that sometimes a program will fail to load, but yet rather than crash, it just keeps trying to load--lagging out my system to the extent that my mouse pointer jerks about. The only way to stop the lag is to reset the X server. It is possible that some aspect of KDE is causing this behaviour, but I'm worried that my disk might be the problem. My hdparm direct readings in Gentoo (with DMA enabled) were:
/dev/hdb:
Timing cached reads: 1164 MB in 2.00 seconds = 580.87 MB/sec
Timing buffered disk reads: 128 MB in 3.02 seconds = 42.36 MB/secIn Arch my direct readings for the same drive are:
/dev/sdb:
Timing cached reads: 586 MB in 2.00 seconds = 293.17 MB/sec
Timing buffered disk reads: 182 MB in 3.03 seconds = 60.14 MB/secNow, you may notice that Arch labels my drive sdb rather than hdb; I don't know whether that has any significance. I performed the tests a few times to get these readings, so they should be accurate. However, it would seem that despite an improvement in buffered disk reads, the cached reads have almost halved. Also, for some reason I can't easily find out whether DMA is enabled like I could in Gentoo because hdparm /dev/sdb returns only:
IO_support = 0 (default 16-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 14593/255/63, sectors = 234441648, start = 0But no mention of DMA. However a 'dmesg | grep -i ata.*dma' returns:
ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001a800 irq 14
ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001a808 irq 15
ata1.00: ATA-5: WDC WD800JB-00CRA1, 17.07W17, max UDMA/100
ata1.01: ATA-6: WDC WD1200JB-00GVC0, 08.02D08, max UDMA/100
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/100
ata2.00: ATAPI: PHILIPS DVDRW416N, 1.C0, max UDMA/33
ata2.01: ATAPI: LG CD-RW CED-8083B, 1.05, max MWDMA2
ata2.00: configured for UDMA/33
ata2.01: configured for MWDMA2I'm assuming that 'configured for UDMA/100' means that DMA is enabled, but why do the cached read times appear substantially slower compared to the readings I recorded in Gentoo?
Last edited by shadeheim (2007-10-10 00:45:33)
Offline
I suspect that the lags might be caused by KDE afterall, but I'll have to wait and see. See here: http://www.linuxquestions.org/questions … s.-585290/ for how to disable artsd in KDE.
If the KDE fix works I suppose I'm not really that bothered about the low cached reads, but I would like the peace of mind in knowing that I'm getting my moneys worth from the drive.
In this thread: http://bbs.archlinux.org/viewtopic.php?id=37547 it is debated whether cached reads are all that important to performance. Nevertheless, others seem to be suffering from significantly lower cached reads, and some claim that it is noticeable.
Perhaps hdparm is just reporting the reads wrong, but I can't make out the readings from Bonnie++, and I don't have another distro installed to compare the readings either.
At least I now suspect why my ide drives were renamed from hda to sda. From 'Persistent block device naming' in Arch Wiki:
With the introduction of the new libata pata support, all your ide hdX devices will become sdX devices at some point in the future.
But is hdparm confused now? It interacts with the drive as if it isn't ide. When I try to set dma:
/dev/sdb:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for deviceJust to confirm that my drive is ide:
lspci | grep sata
lspci | grep -i ide
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)Would compiling my own kernel allow me to use hdparm correctly?
Last edited by shadeheim (2007-10-10 14:11:49)
Offline
Use sdparm (available in the [core] repo) instead of hdparm for /dev/sdX devices (IDE devices which use the SCSI subsystem instead of the IDE subsystem).
Offline
Pages: 1