You are not logged in.
Pages: 1
Hi,
Using arch a few days ago (Recent Instalation) I noticed that it was very slow, programs were taking quite some time to open, then I tested my HD performance with hdparm:
Cached Read is 680MB/s in Arch.
After this, I installed CentOS 5.0 and tested hdparm again:
Cached Read is 1700MB/s in CentOS.
Then I Tested hdparm in Ubuntu 7.04 and in Fedora 7 and:
Cached Read is ~ 622MB/s in both.
My problem is that I want Arch (Of course) with that HD performance found in CentOS.
I want some directions from you guys, I have already searched and tested this for a few days, but can´t make it work.
I can get needed data from bot, Centos or Arch.
Thank you!!
Last edited by William Koch (2007-09-19 16:52:03)
Offline
you likely have an ide hard drive, right?
You probably need to tune the hdparm settings a bit.
What is the output of htparm -I /dev/sda
Where sda is your drive.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
/dev/sda:
ATA device, with non-removable media
Model Number: MDT MD200BB-00CAA1
Serial Number: MDT-MMA8J2059236
Firmware Revision: 17.07W17
Standards:
Supported: 5 4 3
Likely used: 6
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 39102336
device size with M = 1024*1024: 19092 MBytes
device size with M = 1000*1000: 20020 MBytes (20 GB)
Capabilities:
LBA, IORDY(can be disabled)
bytes avail on r/w long: 40
Standby timer values: spec'd by Standard, with device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Recommended acoustic management value: 128, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
SET_MAX security extension
* Automatic Acoustic Management feature set
* Device Configuration Overlay feature set
* SMART error logging
* SMART self-test
Security:
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
HOW DO I TWEAK ?
Are u listening?
Offline
i thought hdparm was useless with scsi drives (even them not being actually scsi but ide like with the new libata thing)
am i wrong?
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
you likely have an ide hard drive, right?
You probably need to tune the hdparm settings a bit.What is the output of hdparm -I /dev/sda
Where sda is your drive.
My HD is a Serial ATA 5400RPM (My computer is a Notebook Toshiba Satellite A135-S2386)
hdparm -I /dev/sda in ArchLinux:
# hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: TOSHIBA MK8037GSX
Serial Number: 37NHF8VJS
Firmware Revision: DL230M
Standards:
Supported: 7 6 5 4
Likely used: 7
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 156301488
LBA48 user addressable sectors: 156301488
device size with M = 1024*1024: 76319 MBytes
device size with M = 1000*1000: 80026 MBytes (80 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: unknown setting (0x0080)
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
* SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* IDLE_IMMEDIATE with UNLOAD
* SATA-I signaling speed (1.5Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
46min for SECURITY ERASE UNIT.
Checksum: correct
hdparm -I /dev/sda in CentOS:
# hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: TOSHIBA MK8037GSX
Serial Number: 37NHF8VJS
Firmware Revision: DL230M
Standards:
Supported: 7 6 5 4
Likely used: 7
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 156301488
LBA48 user addressable sectors: 156301488
device size with M = 1024*1024: 76319 MBytes
device size with M = 1000*1000: 80026 MBytes (80 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: unknown setting (0x0080)
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
* SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* IDLE_IMMEDIATE with UNLOAD
* SATA-I signaling speed ( 1.5Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
46min for SECURITY ERASE UNIT.
Checksum: correct
hdparm -tT /dev/sda in ArchLinux:
/dev/sda:
Timing cached reads: 680 MB in 2.00 seconds = 340.13 MB/sec
Timing buffered disk reads: 130 MB in 3.04 seconds = 42.74 MB/sec
hdparm -tT /dev/sda in CentOS:
/dev/sda:
Timing cached reads: 1632 MB in 2.00 seconds = 816.36 MB/sec
Timing buffered disk reads: 130 MB in 3.03 seconds = 42.85 MB/sec
Could it be some new driver, or something that has changed recently, CentOS is RHEL based, it uses older programs/drivers/kernel.
Thank you!
Last edited by William Koch (2007-09-19 21:09:01)
Offline
i thought hdparm was useless with scsi drives (even them not being actually scsi but ide like with the new libata thing)
am i wrong?
Right. With scsi/sata drives you cannot tune with hdparm. If they are ide drives using the scsi driver, then I think hdparm can still tune some options.
Alas though. It seems he is using SATA drives.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
hmm. I remember something a while back about somebody getting horrible performance with a particular chipset, with new kernels.
centos/rhel generally use older kernels..so that may be relevant here.
The fact that ubuntu and fedora (both using newer kernels too) are just as slow (slower) than arch, seems revealing.
William Koch. do you happen to know what SATA chipset that laptop uses?
lspci should show it.
lspci | grep -i sata
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
hmm. I remember something a while back about somebody getting horrible performance with a particular chipset, with new kernels.
centos/rhel generally use older kernels..so that may be relevant here.
The fact that ubuntu and fedora (both using newer kernels too) are just as slow (slower) than arch, seems revealing.William Koch. do you happen to know what SATA chipset that laptop uses?
lspci should show it.lspci | grep -i sata
I tryed sending this code you said in terminal: lspci | grep -i sata but I got no answer.
Then I tryed: lspci | grep -i ata and I got:
00:12.0 IDE interface: ATI Technologies Inc 4379 Serial ATA Controller (rev 80)
I hope this helps.
Thank you!!
Offline
looks like that chipset is "fakeraid" and apparently uses the sata_sil (silicon 3112 driver).
I *believe* that is the same driver others reported performance issues with later kernels..
That could just be me remembering a familiar name thoug (sata_sil).
This is interesting: http://gentoo-wiki.com/HARDWARE_SATA#SiI_3112_SATA
Not sure if you have both drivers loaded..but check that..
I found a random LKML thread about a problem with sata_sil, from 2004, but it ended up with people saying "just be glad it works at all and you get 30MB/s"..so no help there...
Not sure. You might try a bit of googling on your own..or maybe compare the driver source for those two modules..or something in that gentoo-wiki link.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Not trying to sound harsh and I only skimmed this thread, but ... nobody cares about "cached reads". Sequential throughput matters and that's obviously the same with Arch and CentOS. So, nothing to worry about.
1000
Offline
byte makes a good point.
Try timing with something like a dd run, and see how it measures up.
hdparm performance metrics can be a bit goofy sometimes too.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
You might also try 'hdparm --direct -tT /dev/sda', that should bypass the whole kernel memory stuff and also give results around 42 MB/s.
1000
Offline
maybe this is a kernel issue .. i read somewhere, on this forum i think, that there is a bug in the kernel v 2.6.22 that affects hd performance, apparently it's been fixed in 2.6.23
Offline
I have just Arch:
hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1218 MB in 2.00 seconds = 608.95 MB/sec
Timing buffered disk reads: 128 MB in 3.01 seconds = 42.47 MB/sec
----------------------------------------------------------------------------------------
hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: WDC WD800JB-00FSA0
Serial Number: WD-WCAJD1048022
Firmware Revision: 77.07W77
Standards:
Supported: 6 5 4
Likely used: 6
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 156301488
LBA48 user addressable sectors: 156301488
device size with M = 1024*1024: 76319 MBytes
device size with M = 1000*1000: 80026 MBytes (80 GB)
Capabilities:
LBA, IORDY(can be disabled)
Standby timer values: spec'd by Standard, with device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Recommended acoustic management value: 128, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
SET_MAX security extension
* Automatic Acoustic Management feature set
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
Security:
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
Offline
Perhaps it is a gereral "problem"? I got the following values with nforce4+sata drives:
[root@opteron pierre]# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1362 MB in 2.00 seconds = 680.91 MB/sec
Timing buffered disk reads: 222 MB in 3.02 seconds = 73.51 MB/sec
[root@opteron pierre]# hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 1516 MB in 2.00 seconds = 757.99 MB/sec
Timing buffered disk reads: 212 MB in 3.02 seconds = 70.19 MB/sec
But perhaps this is only a problem with hdparm? Cache reads are read directly from RAM, right? I don't see any reason why this should be slower using Arch.
Last edited by Pierre (2007-09-20 13:05:14)
Offline
In case it helps anything,
I get this on a sata disk with Gigabyte DS4, (ich9 if I'm not mistaken)
~ $ sudo hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 9018 MB in 2.00 seconds = 4513.10 MB/sec
Timing buffered disk reads: 170 MB in 3.01 seconds = 56.54 MB/sec
Offline
You might also try 'hdparm --direct -tT /dev/sda', that should bypass the whole kernel memory stuff and also give results around 42 MB/s.
I did this --direct test, I don't have the exact results right now, cause I am at work, but I got something like:
ArchLinux:
Cached 176MB/s
CentOS:
Cached 356MB/s
What is the command used to measure a program start time? I searched google but haven't found anything.
---------
Cactus:
The driver that is in use is sata_sil indeed, in Arch and in CentOS.
I think this has something to do with these new kernel versions.
Offline
I have tested Foresight Linux 1.3 on this computer and I got the same performance problems, now I have installed the new foresight version, 1.4, and it has the same performance as CentOS 5.
Besides the hdparm testing, I copied some files over my network, and in Foresight it took 15 minutes to move the files, while in Arch it took almost one hour.
Foresight 1.4 Kernel is 2.6.22
I really don't understand what's causing this problem.
Well, I think I will use Foresight for now, I will test the next versions of ArchLinux to see if I can go back to it.
Thank you all for the help.
Offline
I'm getting real sluggish performance aswell.
scj@ghidora:/etc%> dmesg | egrep -i '( |s)ata'
ata1.00: ATA-5: IC35L040AVER07-0, ER4OA44A, max UDMA/100
ata1.01: ATA-7: Maxtor 6Y120L0, YAR41BW0, max UDMA/133
ata2.01: ATAPI: GENERIC CRD-BP1500P, 6z34, max MWDMA2
scsi 0:0:0:0: Direct-Access ATA IC35L040AVER07-0 ER4O PQ: 0 ANSI: 5
scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y120L0 YAR4 PQ: 0 ANSI: 5
sata_sil 0000:00:13.0: version 2.2
scsi2 : sata_sil
scsi3 : sata_sil
ata3: SATA max UDMA/100 cmd 0xe080a080 ctl 0xe080a08a bmdma 0xe080a000 irq 17
ata4: SATA max UDMA/100 cmd 0xe080a0c0 ctl 0xe080a0ca bmdma 0xe080a008 irq 17
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: ATA-7: WDC WD4000KD-00NAB0, 01.06A01, max UDMA/133
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata4.00: ATA-6: WDC WD2000JD-00HBB0, 08.02D08, max UDMA/133
scsi 2:0:0:0: Direct-Access ATA WDC WD4000KD-00N 01.0 PQ: 0 ANSI: 5
scsi 3:0:0:0: Direct-Access ATA WDC WD2000JD-00H 08.0 PQ: 0 ANSI: 5
/dev/sdb: Maxtor 6Y120L0
Timing cached reads: 596 MB in 2.01 seconds = 297.23 MB/sec
Timing buffered disk reads: 170 MB in 3.01 seconds = 56.53 MB/sec
/dev/sdc: WDC WD4000KD-00NAB0
Timing cached reads: 594 MB in 2.00 seconds = 297.04 MB/sec
Timing buffered disk reads: 174 MB in 3.00 seconds = 57.96 MB/sec
/dev/sdd: WDC WD2000JD-00HBB0
Timing cached reads: 570 MB in 2.01 seconds = 284.27 MB/sec
Timing buffered disk reads: 174 MB in 3.03 seconds = 57.45 MB/sec
Offline
Eh, you call 60 MB/s sluggish? Again, who cares about the cache? Wake up.
1000
Offline
Well, one should notice such big difference in cache throughput. And even if not it's is a strange defference. :-) Btw: are there any other program except hdparm to determine how fast the cache is?
Offline
Are there other programs to tune a scsi interface? I mean something usable and not sdparm...
I have a FUJITSU MHW2120BH in my Sony Vaio laptop.
/dev/sda:
Timing cached reads: 1526 MB in 2.00 seconds = 762.93 MB/sec
Timing buffered disk reads: 116 MB in 3.05 seconds = 38.05 MB/sec
I think performance can be improved. But I actually don't know how.
Offline
It's a more or less current 5400 rpm notebook drive, those figures are quite okay actually.
1000
Offline
Pages: 1