poor sata performance on 2.6
Hi,
I recently got a new sata disk and must say that it's performace is totally unacceptable, on both siimage and sata_sil drivers. DMA is turned on.
More details: MB is EPoX 8k9a2+, KT400 chipset, it has embedded Sil3112a SATA controller. HDD is WD740GD (10k RPM, 8MB cache), also tried WD360GD, got absolutely the same results. Tried lots of different 2.6 kernels: 2.6.4-ck1, -ck2, -wolk2.3 and 2.6.5 vanilla and -mm5. No difference. Tried to enable/disable APIC and ACPI and even removed all hardware sharing the same IRQ. Nothing changed. Transfer speed was measured using hdparm -Tt. Results for siimage driver:
/dev/hde:
Timing buffer-cache reads: 1436 MB in 2.00 seconds = 717.03 MB/sec
Timing buffered disk reads: 100 MB in 3.03 seconds = 32.95 MB/sec
for sata_sil:
/dev/sda:
Timing buffer-cache reads: 1412 MB in 2.00 seconds = 705.05 MB/sec
Timing buffered disk reads: 84 MB in 3.06 seconds = 27.43 MB/sec
So my old IDE HDD appears to be considerably faster. Expected results were 55-70MB/s.
Playing with hdparm gives nothing (-d1 -u1 -c1 -X70 -m16 gives +3MB/s 'boost').
hdparm -i:
Model=WDC WD740GD-00FLA0, FwRev=21.08U21, SerialNo=WD-WMAKE1059828 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=off CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=145226112 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
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=no WriteCache=enabled
Drive conforms to: device does not report version:
lspci -vvv output is attached.
dmesg for siimage:
SiI3112 Serial ATA: IDE controller at PCI slot 0000:00:0f.0 SiI3112 Serial ATA: chipset revision 2
SiI3112 Serial ATA: 100% native mode on irq 185
ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio
ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio
hde: WDC WD740GD-00FLA0, ATA DISK drive
ide2 at 0xf99bb080-0xf99bb087,0xf99bb08a on irq 185
hde: max request size: 64KiB
hde: 145226112 sectors (74355 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(133)
hde: unknown partition table
dmesg for libata:
libata version 1.02 loaded.sata_sil version 0.54
PCI: Found IRQ 12 for device 0000:00:0f.0
PCI: Sharing IRQ 12 with 0000:00:0a.0
PCI: Sharing IRQ 12 with 0000:00:10.2
ata1: SATA max UDMA/100 cmd 0xF99B3080 ctl 0xF99B308A bmdma 0xF99B3000 irq 12
ata2: SATA max UDMA/100 cmd 0xF99B30C0 ctl 0xF99B30CA bmdma 0xF99B3008 irq 12
ata1: dev 0 cfg 49:2f00 82:74eb 83:7f63 84:4003 85:74e9 86:3c43 87:4003 88:207f
ata1: dev 0 ATA, max UDMA/133, 145226112 sectors (lba48)
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: no device found (phy stat 00000000)
scsi1 : sata_sil
ata2: thread exiting
Vendor: ATA Model: WDC WD740GD-00FL Rev: 1.02
Type: Direct-Access ANSI SCSI revision: 05
ata1: dev 0 max request 32MB (lba48)
SCSI device sda: 145226112 512-byte hdwr sectors (74356 MB)
SCSI device sda: drive cache: write through
sda:<6>USB Universal Host Controller Interface driver v2.2
PCI: Found IRQ 5 for device 0000:00:10.0
PCI: Sharing IRQ 5 with 0000:00:12.0
(IRQ's are different because first run was with ACPI used for IRQ routing, and second was with 'acpi=off noapic')
I'm really eager to find a solution for this problem.
Thanks
Signature · 2 lines
/KoS * Did you receive a proper socialist education?
Quoting Konstantin Sobolev <[email protected]>:
Quoted 4 lines
/dev/hde:
Timing buffer-cache reads: 1436 MB in 2.00 seconds = 717.03 MB/sec
Timing buffered disk reads: 100 MB in 3.03 seconds = 32.95 MB/sec
Quoted 8 lines
for
sata_sil:
/dev/sda:
Timing buffer-cache reads: 1412 MB in 2.00 seconds = 705.05 MB/sec
Timing buffered disk reads: 84 MB in 3.06 seconds = 27.43 MB/secSo my old IDE HDD appears to be considerably faster. Expected results were 55-70MB/s.
Which kernel version did you get these results using? Have you speed-tested the drive(s) on a different SATA controller? I don't mean to imply that you should buy another one - that would be rediculuous since your motherboard should laready has it - but it would help to eliminate possible causes of error. I took the same readings on my machine. I'm using an ASUS SK8N motherboard - that's the Promise TX2 SATA controller - with Western Digital's 36gb 10K RPM Raptor:
/dev/sda:
Timing buffer-cache reads: 128 MB in 0.12 seconds =1075.79 MB/sec
Timing buffered disk reads: 64 MB in 1.20 seconds = 53.43 MB/sec
I'm using the latest stable vanilla kernel (2.6.5), compiled today. It would also help to have your kernel config, if at all possible.
-Ryan
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
Quoted 6 lines · Konstantin Sobolev
Hi,
/dev/hde:Timing buffer-cache reads: 1436 MB in 2.00 seconds = 717.03 MB/sec Timing buffered disk reads: 100 MB in 3.03 seconds = 32.95 MB/sec
Quoted 9 lines
for
sata_sil:
/dev/sda:Timing buffer-cache reads: 1412 MB in 2.00 seconds = 705.05 MB/sec Timing buffered disk reads: 84 MB in 3.06 seconds = 27.43 MB/secSo my old IDE HDD appears to be considerably faster. Expected results were 55-70MB/s.
With same hard drive connected to 3ware S-ATA controller I got 40-50MB/sec with hdparm on 2.6.4 and 2.6.5. Then tried to hdparm -a 8192 /dev/sda, and got this:
/dev/sda:
Timing buffer-cache reads: 2056 MB in 2.00 seconds = 1027.13 MB/sec Timing buffered disk reads: 266 MB in 3.00 seconds = 88.53 MB/sec
So you may try that switch, maybe helps.
Lenar
Quoted 13 lines · Lenar Lõhmus
Quoted 8 lines
for
sata_sil:
/dev/sda:Timing buffer-cache reads: 1412 MB in 2.00 seconds = 705.05 MB/sec Timing buffered disk reads: 84 MB in 3.06 seconds = 27.43 MB/secSo my old IDE HDD appears to be considerably faster. Expected results were 55-70MB/s.
With same hard drive connected to 3ware S-ATA controller I got 40-50MB/sec with hdparm on 2.6.4 and 2.6.5. Then tried to hdparm -a 8192
/dev/sda, and got this:
Quoted 5 lines
/dev/sda:
Timing buffer-cache reads: 2056 MB in 2.00 seconds = 1027.13 MB/sec
Timing buffered disk reads: 266 MB in 3.00 seconds = 88.53 MB/secSo you may try that switch, maybe helps.
unfortunately it doesn't:
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 84 MB in 3.06 seconds = 27.46 MB/sec
Signature · 2 lines
/KoS * Searching for light in the darkness of insanity.
Quoted 6 lines · Ryan Geoffrey Bourgeois
Quoted 6 lines
/dev/hde:
Timing buffer-cache reads: 1436 MB in 2.00 seconds = 717.03 MB/sec
Timing buffered disk reads: 100 MB in 3.03 seconds = 32.95 MB/secfor
sata_sil:
Quoted 8 lines
Quoted 6 lines
/dev/sda:
Timing buffer-cache reads: 1412 MB in 2.00 seconds = 705.05 MB/sec
Timing buffered disk reads: 84 MB in 3.06 seconds = 27.43 MB/secSo my old IDE HDD appears to be considerably faster. Expected results were 55-70MB/s.
Which kernel version did you get these results using? Have you
Results are the same on different kernels, I tried 2.6.4-ck1 and -ck2, 2.6.4-wolk2.3, 2.6.5 vanilla and 2.6.5-mm5
Quoted 1 line
speed-tested the drive(s) on a different SATA controller? I don't mean to
Not yet, but I'm going to test it on Intel ICH5 soon.
Quoted 3 lines
imply that you should buy another one - that would be rediculuous since your motherboard should laready has it - but it would help to eliminate possible causes of error. I took the same readings on my machine. I'm
I'm almost ready to buy separate controller, but all that I could find nearby are based on the same Silicon Image chipset
Quoted 9 lines
using an ASUS SK8N motherboard - that's the Promise TX2 SATA controller - with Western Digital's 36gb 10K RPM Raptor:
/dev/sda:
Timing buffer-cache reads: 128 MB in 0.12 seconds =1075.79 MB/sec
Timing buffered disk reads: 64 MB in 1.20 seconds = 53.43 MB/secI'm using the latest stable vanilla kernel (2.6.5), compiled today. It would also help to have your kernel config, if at all possible.
Sure. Attached is .config for 2.6.5-mm5
Thanks
Signature · 2 lines
/KoS * If you can't say it in 50 characters, then don't b
Ah I see from your config you have himem_4G turned on. How much memory do you have? Sii3112 appears (I dont actually have datasheets) to only have 32 bit DMA support, and will use bounce buffers quite a lot of the time if you turn on himem at all, reducing throughput substantially. Try again with no himem support at all and see if it helps.
Justin
Quoted 42 lines · Konstantin Sobolev
Quoted 6 lines · Ryan Geoffrey Bourgeois
Quoted 6 lines
/dev/hde:
Timing buffer-cache reads: 1436 MB in 2.00 seconds = 717.03 MB/sec
Timing buffered disk reads: 100 MB in 3.03 seconds = 32.95 MB/secfor
sata_sil:Quoted 8 lines
Quoted 6 lines
/dev/sda:
Timing buffer-cache reads: 1412 MB in 2.00 seconds = 705.05 MB/sec
Timing buffered disk reads: 84 MB in 3.06 seconds = 27.43 MB/secSo my old IDE HDD appears to be considerably faster. Expected results were 55-70MB/s.
Which kernel version did you get these results using? Have you
Results are the same on different kernels, I tried 2.6.4-ck1 and -ck2, 2.6.4-wolk2.3, 2.6.5 vanilla and 2.6.5-mm5
Quoted 1 line
speed-tested the drive(s) on a different SATA controller? I don't mean to
Not yet, but I'm going to test it on Intel ICH5 soon.
Quoted 3 lines
imply that you should buy another one - that would be rediculuous since your motherboard should laready has it - but it would help to eliminate possible causes of error. I took the same readings on my machine. I'm
I'm almost ready to buy separate controller, but all that I could find nearby are based on the same Silicon Image chipset
Quoted 9 lines
using an ASUS SK8N motherboard - that's the Promise TX2 SATA controller - with Western Digital's 36gb 10K RPM Raptor:
/dev/sda:
Timing buffer-cache reads: 128 MB in 0.12 seconds =1075.79 MB/sec
Timing buffered disk reads: 64 MB in 1.20 seconds = 53.43 MB/secI'm using the latest stable vanilla kernel (2.6.5), compiled today. It would also help to have your kernel config, if at all possible.
Sure. Attached is .config for 2.6.5-mm5
Thanks
Quoted 18 lines · Konstantin Sobolev
Quoted 17 lines · Lenar Lõhmus
Quoted 8 lines
for
sata_sil:
/dev/sda:Timing buffer-cache reads: 1412 MB in 2.00 seconds = 705.05 MB/sec Timing buffered disk reads: 84 MB in 3.06 seconds = 27.43 MB/secSo my old IDE HDD appears to be considerably faster. Expected results were 55-70MB/s.
With same hard drive connected to 3ware S-ATA controller I got 40-50MB/sec with hdparm on 2.6.4 and 2.6.5. Then tried to hdparm -a 8192
/dev/sda, and got this:
/dev/sda:
Timing buffer-cache reads: 2056 MB in 2.00 seconds = 1027.13 MB/sec
Timing buffered disk reads: 266 MB in 3.00 seconds = 88.53 MB/sec
Quoted 8 lines
Quoted 1 line
So you may try that switch, maybe helps.
unfortunately it doesn't:
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 84 MB in 3.06 seconds = 27.46 MB/sec
27 Mb/s is not 'very' bad for 80Gb drive.
Can you verify that drive indeed is able to do better (quick test under Windows is in order)? It would be silly to try to hunt down problem which do not exist.
If problem does exist, try 2.4 kernels.
Signature · 1 line
vda
Quoted 9 lines · Denis Vlasenko
27 Mb/s is not 'very' bad for 80Gb drive.
Can you verify that drive indeed is able to do better (quick test under Windows is in order)? It would be silly to try to hunt down problem which do not exist.
If problem does exist, try 2.4 kernels.
This drive really _can_ do _much_ better. At least order of two. In my case - order of three.
Lenar
Quoted 10 lines · Denis Vlasenko
Quoted 4 lines
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 84 MB in 3.06 seconds = 27.46 MB/sec27 Mb/s is not 'very' bad for 80Gb drive.
Can you verify that drive indeed is able to do better (quick test under Windows is in order)? It would be silly to try to hunt down problem which do not exist.
Here's this drive benchmarks under Windows on almost the same SATA controller:
http://www.tomshardware.com/storage/20040123/wd740-01.html
actual numbers:
http://www.tomshardware.com/storage/20040123/wd740-08.html
It appears to be the fastest SATA drive up to the moment, I expected to get something around 60-70 MB/sec
Quoted 2 lines
If problem does exist, try 2.4 kernels.
I tried 2.4.25. There is no sata_sil driver there. siimage driver detects the controller but doesn't detect the disk:
SiI3112 Serial ATA: IDE controller at PCI slot 00:0f.0
PCI: Found IRQ 12 for device 00:0f.0
PCI: Sharing IRQ 12 with 00:0a.0
PCI: Sharing IRQ 12 with 00:10.2
SiI3112 Serial ATA: chipset revision 2
SiI3112 Serial ATA: not 100% native mode: will probe irqs later
ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio
ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio
that's all
Signature · 2 lines
/KoS * A fool and his money are my kind of customer.
Quoted 5 lines · Justin Cormack
Ah I see from your config you have
himem_4Gturned on. How much memory do you have? Sii3112 appears (I dont actually have datasheets) to only have 32 bit DMA support, and will use bounce buffers quite a lot of the time if you turn on himem at all, reducing throughput substantially. Try again with no himem support at all and see if it helps.
I have 1.5 GB. I tried to disable highmem, now less than 1GB is visible, but there is no noticable difference in SATA performance:
siimage:/dev/hde:
setting fs readahead to 8129
setting 32-bit IO_support flag to 1
setting multcount to 16
multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8128 (on) geometry = 16383/255/63, sectors = 145226112, start = 0
Timing buffer-cache reads: 1428 MB in 2.00 seconds = 713.75 MB/sec
Timing buffered disk reads: 100 MB in 3.03 seconds = 32.99 MB/sec
libata/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 82 MB in 3.02 seconds = 27.17 MB/sec
Signature · 2 lines
/KoS * Popularity is not the same as validity.
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci, /proc/interrupts and dmesg...
Justin
Quoted 31 lines · Konstantin Sobolev
Quoted 5 lines · Justin Cormack
Ah I see from your config you have
himem_4Gturned on. How much memory do you have? Sii3112 appears (I dont actually have datasheets) to only have 32 bit DMA support, and will use bounce buffers quite a lot of the time if you turn on himem at all, reducing throughput substantially. Try again with no himem support at all and see if it helps.I have 1.5 GB. I tried to disable highmem, now less than 1GB is visible, but there is no noticable difference in SATA performance:
siimage:
/dev/hde:
setting fs readahead to 8129
setting 32-bitIO_supportflag to 1
setting multcount to 16multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8128 (on) geometry = 16383/255/63, sectors = 145226112, start = 0Timing buffer-cache reads: 1428 MB in 2.00 seconds = 713.75 MB/sec
Timing buffered disk reads: 100 MB in 3.03 seconds = 32.99 MB/seclibata
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 82 MB in 3.02 seconds = 27.17 MB/sec
Quoted 3 lines · Justin Cormack
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci,
/proc/interruptsand dmesg...
Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
Signature · 2 lines
/KoS * Are you into transmogrification, too?
Quoted 6 lines · Konstantin Sobolev
Quoted 3 lines · Justin Cormack
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci,
/proc/interruptsand dmesg...Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
ah. Make a filesystem on it and mount it and try again. I see you have no partition table and so probably no filesystem. This means the block size is set to default 512byte not 4k which makes disk operations slow. Any filesystem should default to block size of 4k, eg ext2.
Justin
Quoted 6 lines · Justin Cormack
Quoted 5 lines · Konstantin Sobolev
Quoted 3 lines · Justin Cormack
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci,
/proc/interruptsand dmesg...
Quoted 6 lines
Quoted 1 line
Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
ah. Make a filesystem on it and mount it and try again. I see you have no partition table and so probably no filesystem. This means the block size is set to default 512byte not 4k which makes disk operations slow. Any filesystem should default to block size of 4k, eg ext2.
Very interesting!
created partition table,
kos sata # mkfs.ext2 /dev/sda1
[..skipped..]
kos mnt # cd /
kos / # mkdir wd
kos / # mount /dev/sda1 /wd
kos / # hdparm -t -a8192 /dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 82 MB in 3.03 seconds = 27.02 MB/sec
kos / # mount | grep sda/dev/sda1 on /wd type ext2 (rw)
kos / # hdparm -t -a8192 /dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.15 MB/sec
kos / # hdparm -t -a8192 /dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.18 MB/sec
So first time it gave the same loosy 27 MB/s and subsequent tests give pretty good 68 MB/s! Why?
/KoS
* I haven't lost my mind...It's backed up somewhere!
Quoted 26 lines · Konstantin Sobolev
Quoted 8 lines · Justin Cormack
Quoted 6 lines · Konstantin Sobolev
Quoted 3 lines · Justin Cormack
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci,
/proc/interruptsand dmesg...Quoted 6 lines
Quoted 1 line
Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
ah. Make a filesystem on it and mount it and try again. I see you have no partition table and so probably no filesystem. This means the block size is set to default 512byte not 4k which makes disk operations slow. Any filesystem should default to block size of 4k, eg ext2.
Very interesting!
created partition table,
kos sata # mkfs.ext2/dev/sda1
[..skipped..]
kos mnt # cd /
kos / # mkdir wd
kos / # mount/dev/sda1/wd
kos / # hdparm -t -a8192/dev/sda
[snip]
Quoted 1 line
So first time it gave the same loosy 27 MB/s and subsequent tests give pretty good 68 MB/s! Why?
I once reported that to lkml but got no reaction. siimage.c doesn't show this behaviour.
Prakash
Quoted 38 lines · Konstantin Sobolev
Quoted 6 lines · Justin Cormack
Quoted 5 lines · Konstantin Sobolev
Quoted 3 lines · Justin Cormack
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci,
/proc/interruptsand dmesg...Quoted 6 lines
Quoted 1 line
Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
ah. Make a filesystem on it and mount it and try again. I see you have no partition table and so probably no filesystem. This means the block size is set to default 512byte not 4k which makes disk operations slow. Any filesystem should default to block size of 4k, eg ext2.
Very interesting!
created partition table,
kos sata # mkfs.ext2/dev/sda1
[..skipped..]
kos mnt # cd /
kos / # mkdir wd
kos / # mount/dev/sda1/wd
kos / # hdparm -t -a8192/dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 82 MB in 3.03 seconds = 27.02 MB/seckos / # mount | grep sda
/dev/sda1on /wd type ext2 (rw)
kos / # hdparm -t -a8192/dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.15 MB/sec
kos / # hdparm -t -a8192/dev/sda
Quoted 7 lines
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.18 MB/secSo first time it gave the same loosy 27 MB/s and subsequent tests give pretty good 68 MB/s! Why?
Ah yes, I noticed that once or twice. Not sure what the reason is. It may be something to do with how hdparm tries to deal with bypassing the vm, or how the scsi layer deals with block size changes or something. I wouldnt worry. It only happens if you do hdparm ever when the block size is 512bytes. 68MB/s is pretty nice. Was thinking of getting some of those drives.
Justin
Quoted 6 lines · Justin Cormack
Ah yes, I noticed that once or twice. Not sure what the reason is. It may be something to do with how hdparm tries to deal with bypassing the vm, or how the scsi layer deals with block size changes or something. I wouldnt worry. It only happens if you do hdparm ever when the block size is 512bytes. 68MB/s is pretty nice. Was thinking of getting some of those drives.
Thanks a lot! :)
Signature · 2 lines
/KoS * Life with pets is never dull.
Quoted 6 lines
I'm almost ready to buy separate controller, but all that I could find nearby
are based on the same Silicon Image chipset
I do recomend Promise's SATA controller cards. The kernel drivers are excellent imho. As well as my onboard Promise TX2, I'm using a thei S150 SX4 RAID5 capable controller in my file server. A controlle ard should be easy enough to finnd online. I shop at NewEgg.com. Good prices, highly rcommended.
I'm gonna take a look at your .config as soon as I get back to my own computer.
Cheers.
-Ryan
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
Quoted 11 lines · Lenar Lõhmus
Quoted 7 lines · Denis Vlasenko
27 Mb/s is not 'very' bad for 80Gb drive.
Can you verify that drive indeed is able to do better (quick test under Windows is in order)? It would be silly to try to hunt down problem which do not exist.
If problem does exist, try 2.4 kernels.
This drive really _can_ do _much_ better. At least order of two. In my case - order of three.
I don't believe any drive can do 27000 Mb/s ;)
You probably meant 'three times more throughput', which can very well be true.
--
vda
Quoted 39 lines · Konstantin Sobolev
Quoted 6 lines · Justin Cormack
Quoted 5 lines · Konstantin Sobolev
Quoted 3 lines · Justin Cormack
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci,
/proc/interruptsand dmesg...Quoted 7 lines
Quoted 2 lines
Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
ah. Make a filesystem on it and mount it and try again. I see you have no partition table and so probably no filesystem. This means the block size is set to default 512byte not 4k which makes disk operations slow. Any filesystem should default to block size of 4k, eg ext2.
Very interesting!
created partition table,
kos sata # mkfs.ext2/dev/sda1
[..skipped..]
kos mnt # cd /
kos / # mkdir wd
kos / # mount/dev/sda1/wd
kos / # hdparm -t -a8192/dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 82 MB in 3.03 seconds = 27.02 MB/seckos / # mount | grep sda
/dev/sda1on /wd type ext2 (rw)
kos / # hdparm -t -a8192/dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.15 MB/sec
kos / # hdparm -t -a8192/dev/sda
Quoted 7 lines
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.18 MB/secSo first time it gave the same loosy 27 MB/s and subsequent tests give pretty good 68 MB/s! Why?
Time to CC ide/libata/block layer folks
Jeff Garzik <[email protected]>
libata man
IDE DRIVER [GENERAL]
P: Bartlomiej Zolnierkiewicz M: [email protected] L: [email protected] L: [email protected] S: Maintained
BLOCK LAYER
P: Jens Axboe M: [email protected] L: [email protected] S: Maintained
SIS 5513 IDE CONTROLLER DRIVER
P: Lionel Bouton M: [email protected] W: http://inet6.dyn.dhs.org/sponsoring/sis5513/index.html W: http://gyver.homeip.net/sis5513/index.html S: Maintained
--
vda
Hi!
Quoted 2 lines
I recently got a new sata disk and must say that it's performace is totally unacceptable, on both siimage and
sata_sildrivers. DMA is turned on.
...
Quoted 3 lines
/dev/hde:
Timing buffer-cache reads: 1436 MB in 2.00 seconds = 717.03 MB/sec
Timing buffered disk reads: 100 MB in 3.03 seconds = 32.95 MB/sec
33MB/sec "totally unacceptable"? Wow.
Quoted 1 line
* Did you receive a proper socialist education?
Only half of it ;-)
Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Quoted 5 lines · Pavel Machek
Quoted 3 lines
/dev/hde:
Timing buffer-cache reads: 1436 MB in 2.00 seconds = 717.03 MB/sec
Timing buffered disk reads: 100 MB in 3.03 seconds = 32.95 MB/sec33MB/sec "totally unacceptable"? Wow.
well.. taking into account it's price and final 68MB/sec I've got after following Justin's advice.. :)
Signature · 2 lines
/KoS * Jeez, if you love Honkus...
Quoted 12 lines · Ryan Geoffrey Bourgeois
Quoted 6 lines
I'm almost ready to buy separate controller, but all that I could find nearby
are based on the same Silicon Image chipset
I do recomend Promise's SATA controller cards. The kernel drivers are excellent imho. As well as my onboard Promise TX2, I'm using a thei S150 SX4 RAID5 capable controller in my file server. A controlle ard should be easy enough to finnd online. I shop at NewEgg.com. Good prices, highly rcommended.
Quoted 8 lines
I'm gonna take a look at your .config as soon as I get back to my own computer.
Cheers.
-Ryan-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
What kernel/driver are you using for the S150 SX4? I couldn't ever get better than 13MB/sec from it in 2.6. Of course, the last I tried was 2.6.3. I could get 55MB/sec using 2.4 and Promise's partial source driver, but since my onboard SATA controller works fine in 2.6 I'm just using that meanwhile.
Thanks,
Simon
Re: poor sata performance on 2.6 - Promise SX4
Quoted 10 lines
What kernel/driver are you using for the S150 SX4? I couldn't ever get better than 13MB/sec from it in 2.6. Of course, the last I tried was 2.6.3. I could get 55MB/sec using 2.4 and Promise's partial source driver, but since my onboard SATA controller works fine in 2.6 I'm just using that meanwhile.
Thanks,
Simon
The performance isn't that great at the moment. Poor driver support for the SX4 right now, as it's kinda the odd card in the lot. The way it handles its hardware RAID is kinda unique from what I've heard. I'm using the sata_promise driver on the 2.6.5 kernel. In the works is supposed to be a separate driver specifically for the SX4, which is the main reason I joined the linux-ide list in the first place. Due to the SX4's unique approach to hardware RAID5, there is not yet a driver that supports RAID5 arrays on the controller, and so each drive can only be accessed separately. Thus I'm using Linux's software RAID5 for my three Western Digital 120gb drives (WD1200JD I think). I got about 25mb/s read time on a drive connected to the controller. It really is below par, but it's getting the job done until we get a good driver.
-Ryan
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
Quoted 5 lines · Simon Koch
Quoted 2 lines · Ryan Geoffrey Bourgeois
I do recomend Promise's SATA controller cards. The kernel drivers are excellent imho. As well as my onboard Promise TX2, I'm using a thei S150 SX4 RAID5
What kernel/driver are you using for the S150 SX4? I couldn't ever get better than 13MB/sec from it in 2.6. Of course, the last I tried was 2.6.3. I could get 55MB/sec using 2.4 and Promise's partial source driver, but since my onboard SATA controller works fine in 2.6 I'm just using that meanwhile.
Re-read his message. He is using TX2, not SX4.
SX4 is vastly different. Each request must bounce through a DIMM, which hurts performance. Further, only one DIMM copy to/from system memory can be occuring at any one time, while you can be executing up to 4 ATA commands (one for each SATA port) in parallel.
SX4 performance currently suffers because of this bounce through the DIMM. Two transactions, and two interrupts, are required for each disk transaction.
SX4 is really designed for RAID acceleration. One may to improve performance (which I plan to implement) is using the DIMM as a write-through cache.
Another way to improve performance on SX4 is to have a special RAID driver which issues RAID1 or RAID5 reads and writes as a single transaction, thus maximizing the potential of the DIMM and cutting in _half_ the PCI bus bandwidth used for writes. SX4, like other Promise products, can also offload RAID5 XOR calculations onto the hardware.
I _really_ like the SX4 -- it gives the programmer full control over all aspects of RAID operation, while providing useful hardware acceleration where it's needed. And not getting in the way of the programmer, when it's not needed.
But currently, my libata driver does not use the advanced features, and so there is a performance hit.
Jeff
Quoted 49 lines · Denis Vlasenko
Quoted 47 lines · Konstantin Sobolev
Quoted 8 lines · Justin Cormack
Quoted 6 lines · Konstantin Sobolev
Quoted 3 lines · Justin Cormack
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci,
/proc/interruptsand dmesg...Quoted 7 lines
Quoted 2 lines
Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
ah. Make a filesystem on it and mount it and try again. I see you have no partition table and so probably no filesystem. This means the block size is set to default 512byte not 4k which makes disk operations slow. Any filesystem should default to block size of 4k, eg ext2.
Very interesting!
created partition table,
kos sata # mkfs.ext2/dev/sda1
[..skipped..]
kos mnt # cd /
kos / # mkdir wd
kos / # mount/dev/sda1/wd
kos / # hdparm -t -a8192/dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 82 MB in 3.03 seconds = 27.02 MB/seckos / # mount | grep sda
/dev/sda1on /wd type ext2 (rw)
kos / # hdparm -t -a8192/dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.15 MB/sec kos / # hdparm -t -a8192/dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.18 MB/sec
Quoted 8 lines
Quoted 2 lines
So first time it gave the same loosy 27 MB/s and subsequent tests give pretty good 68 MB/s! Why?
Time to CC ide/libata/block layer folks
Jeff Garzik <[email protected]>
libata man
It seems like the situation is already resolved, to me.
When you mount a filesystem, it changes the default block size (512 or 1024) to the filesystem block size, normally 4096. This would certainly increase the throughput.
Jeff
Quoted 51 lines · Jeff Garzik
Quoted 50 lines · Denis Vlasenko
Quoted 39 lines · Konstantin Sobolev
Quoted 6 lines · Justin Cormack
Quoted 5 lines · Konstantin Sobolev
Quoted 3 lines · Justin Cormack
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci,
/proc/interruptsand dmesg...Quoted 7 lines
Quoted 2 lines
Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
ah. Make a filesystem on it and mount it and try again. I see you have no partition table and so probably no filesystem. This means the block size is set to default 512byte not 4k which makes disk operations slow. Any filesystem should default to block size of 4k, eg ext2.
Very interesting!
created partition table,
kos sata # mkfs.ext2/dev/sda1
[..skipped..]
kos mnt # cd /
kos / # mkdir wd
kos / # mount/dev/sda1/wd
kos / # hdparm -t -a8192/dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 82 MB in 3.03 seconds = 27.02 MB/seckos / # mount | grep sda
/dev/sda1on /wd type ext2 (rw)
kos / # hdparm -t -a8192/dev/sda
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.15 MB/sec kos / # hdparm -t -a8192/dev/sdaQuoted 7 lines
/dev/sda:
setting fs readahead to 8192
readahead = 8192 (on)
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.18 MB/secSo first time it gave the same loosy 27 MB/s and subsequent tests give pretty good 68 MB/s! Why?
Time to CC ide/libata/block layer folks
Quoted 8 lines
Quoted 2 lines
Jeff Garzik <[email protected]>
libata manIt seems like the situation is already resolved, to me.
When you mount a filesystem, it changes the default block size (512 or 1024) to the filesystem block size, normally 4096. This would certainly increase the throughput.
Yes, this works.
But if one uses unpartitioned disk, why does (s)he need to
do some blocksize tricks before hdparm starts to measure good performance? I think that in this case block layer can coalesce small read requests into large ones regardless of block size.
Konstantin, does dd give you the same behaviour as hdparm? --
vda
Quoted 4 lines · Denis Vlasenko
Quoted 3 lines
When you mount a filesystem, it changes the default block size (512 or 1024) to the filesystem block size, normally 4096. This would certainly increase the throughput.
Quoted 8 lines
Yes, this works.
But if one uses unpartitioned disk, why does (s)he need to
do some blocksize tricks before hdparm starts to measure good performance? I think that in this case block layer can coalesce small read requests into large ones regardless of block size.Konstantin, does dd give you the same behaviour as hdparm?
Sorry, I already partitioned it and put lots of data there.
But situation is reproducible by removing all /dev/sda entries from fstab and rebooting. Here are results of my experiments with dd:
kos root # bash -c "sleep 10 && killall -3 dd &" && LANG=C time dd if=/dev/sda of=/dev/null ibs=512 obs=512 537152+0 records in
537152+0 records out
Command terminated by signal 3
0.23user 3.73system 0:10.07elapsed 39%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+121minor)pagefaults 0swaps
kos root # hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 84 MB in 3.07 seconds = 27.37 MB/sec
kos root # bash -c "sleep 10 && killall -3 dd &" && LANG=C time dd if=/dev/sda of=/dev/null ibs=4096 obs=4096 71691+0 records in
71691+0 records out
Command terminated by signal 3
0.07user 3.83system 0:10.08elapsed 38%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+122minor)pagefaults 0swaps
kos root # mount /dev/sda2 /wd kos root # hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 84 MB in 3.07 seconds = 27.38 MB/sec
kos root # hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 206 MB in 3.02 seconds = 68.13 MB/sec
kos root # bash -c "sleep 10 && killall -3 dd &" && LANG=C time dd if=/dev/sda of=/dev/null ibs=512 obs=512 1402384+0 records in
1402384+0 records out
Command terminated by signal 3
0.54user 2.57system 0:10.02elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+121minor)pagefaults 0swaps
kos root # bash -c "sleep 10 && killall -3 dd &" && LANG=C time dd if=/dev/sda of=/dev/null ibs=4096 obs=4096 329705+0 records in
329705+0 records out
Command terminated by signal 3
0.32user 2.43system 0:10.13elapsed 27%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+122minor)pagefaults 0swaps
It looks like dd behaves similarly to hdparm
Signature · 2 lines
/KoS * yas eh d'tahW. ююmih raeh uoy diD
Quoted 9 lines · Denis Vlasenko
Quoted 5 lines · Jeff Garzik
It seems like the situation is already resolved, to me.
When you mount a filesystem, it changes the default block size (512 or 1024) to the filesystem block size, normally 4096. This would certainly increase the throughput.
Quoted 6 lines
Yes, this works.
But if one uses unpartitioned disk, why does (s)he need to
do some blocksize tricks before hdparm starts to measure good performance? I think that in this case block layer can coalesce small read requests into large ones regardless of block size.
debian unstable
kernel 2.6.5 with udev
promise sata150 tx4
dual seagate ST3120026AS (120GB)
libata 1.02sata_promise 0.91
Thank you all!
I use lvm2 with /dev/sda and /dev/sdb as members of my volume group. That means, no partition tables. The logical volume contains a ReiserFS. Once the logical volume is mounted the higher transfer rates are seen.
22 root@chaljin:/mnt # mount /dev/sdb1 sdb1
23 root@chaljin:/mnt # mount | grep sdb
/dev/scsi/host1/bus0/target0/lun0/part1 on /mnt/sdb1 type ext2 (rw)
24 root@chaljin:/mnt # hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 32 MB in 3.04 seconds = 10.52 MB/sec
25 root@chaljin:/mnt # hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 166 MB in 3.02 seconds = 54.98 MB/sec
26 root@chaljin:/mnt # umount /dev/sdb1
Ah, the change is not stable either. If I umount the partition it reverts to the slower rate. There is no need to reboot.
Quoted 3 lines
Konstantin, does dd give you the same behaviour as hdparm? --
vda
Yes, dd does behave the same as hdparm.
39 root@chaljin:/root # dd bs=512 count=65536 if=/dev/sdb of=/dev/null
65536+0 records in
65536+0 records out
33554432 bytes transferred in 3.203750 seconds (10473487 bytes/sec)
40 root@chaljin:/root # cd /mnt
41 root@chaljin:/mnt # mount /dev/sdb1 sdb1
42 root@chaljin:/mnt # dd bs=512 count=65536 if=/dev/sdb of=/dev/null
65536+0 records in
65536+0 records out
33554432 bytes transferred in 3.184339 seconds (10537330 bytes/sec)
43 root@chaljin:/mnt # dd bs=512 count=65536 if=/dev/sdb of=/dev/null
65536+0 records in
65536+0 records out
33554432 bytes transferred in 0.400394 seconds (83803552 bytes/sec)
44 root@chaljin:/mnt # dd bs=512 count=339968 if=/dev/sdb of=/dev/null
339968+0 records in
339968+0 records out
174063616 bytes transferred in 2.705558 seconds (64335569 bytes/sec)
45 root@chaljin:/mnt #
If anyone wants further testing just let me know. I still have one blank disk and one promise sata150 tx4 controller that is not yet in use.
-cira
(I'm on the linux-ide list)
[cut]
Quoted 1 line
I _really_ like the SX4 -- it gives the programmer full control over all aspects of RAID operation, while providing useful hardware acceleration where it's needed. And not getting in the way of the programmer, when it's not needed.
Does this mean that the hardware-accelerated RAID5-mode will be compatible with soft-RAID5? So that I am able to create a RAID5-array today and get all the goodies from hardware-support later without having to do the backup - recreate-array - restore dance?
[cut]
// Henrik Gustafsson
Quoted 6 lines · Henrik Gustafsson
[cut]
Quoted 1 line
I _really_ like the SX4 -- it gives the programmer full control over all aspects of RAID operation, while providing useful hardware acceleration where it's needed. And not getting in the way of the programmer, when it's not needed.
Does this mean that the hardware-accelerated RAID5-mode will be compatible with soft-RAID5? So that I am able to create a RAID5-array today and get all the goodies from hardware-support later without having to do the backup - recreate-array - restore dance?
Who knows. It depends on the XOR algorithm block size and such. I _think_ XOR'ing is compatible, but have not tested to verify that assertion.
Jeff
Quoted 24 lines · Jeff Garzik
Quoted 22 lines · Denis Vlasenko
Quoted 20 lines · Konstantin Sobolev
Quoted 17 lines · Justin Cormack
Quoted 9 lines · Konstantin Sobolev
Quoted 3 lines · Justin Cormack
hmm, odd. I get 50MB/s or so from normal (7200, 8MB cache) WD disks, and Seagate from the same controller. Can you send lspci,
/proc/interruptsand dmesg...Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
ah. Make a filesystem on it and mount it and try again. I see you have no partition table and so probably no filesystem. This means the block size is set to default 512byte not 4k which makes disk operations slow. Any filesystem should default to block size of 4k, eg ext2.
[snip]
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
So first time it gave the same loosy 27 MB/s and subsequent tests give pretty good 68 MB/s! Why?
Time to CC ide/libata/block layer folks
Quoted 8 lines
Quoted 2 lines
Jeff Garzik <[email protected]>
libata manIt seems like the situation is already resolved, to me.
When you mount a filesystem, it changes the default block size (512 or 1024) to the filesystem block size, normally 4096. This would certainly increase the throughput.
Hi Jeff,
it is NOT resolved: I just tried libata again, and I can observe the same behaviour: I just did a "cat /dev/sda >/dev/null" and watched gkrellm2 showing the throughoutput. The first tiem I do the cat I only got about 27mb/s, no matter how ong I waited, but all subsequent cat gave me about >60mb/s. So there is a tiny bug in libata, I guess, as when using the siimage.c ide driver, already the first cat gives me maximum throughoutput. I am using 2.6.5-mm4 based kernel. Filesystems were mounted/ I didn't change anything between first and secound cat.
bye,
Prakash
It works fine on my SATA disk:
[root@flxible root]# hdparm -Tt /dev/sdb
/dev/sdb:
Timing buffer-cache reads: 3916 MB in 2.00 seconds = 1956.09 MB/sec
Timing buffered disk reads: 174 MB in 3.01 seconds = 57.85 MB/sec