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
--
/KoS
* Did you receive a proper socialist education?
Quoting Konstantin Sobolev <[email protected]>:
> /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.
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/
Konstantin Sobolev wrote:
>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
>
>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.
>
>
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
On Thursday 15 April 2004 11:12, Lenar L?hmus wrote:
> >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.
>
> 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.
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
--
/KoS
* Searching for light in the darkness of insanity.
On Thursday 15 April 2004 07:54, Ryan Geoffrey Bourgeois wrote:
> > /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.
>
> 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
> 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.
> 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
> 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.
Sure. Attached is .config for 2.6.5-mm5
Thanks
--
/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
On Thu, 2004-04-15 at 11:55, Konstantin Sobolev wrote:
> On Thursday 15 April 2004 07:54, Ryan Geoffrey Bourgeois wrote:
> > > /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.
> >
> > 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
>
> > 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.
>
> > 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
>
> > 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.
>
> Sure. Attached is .config for 2.6.5-mm5
> Thanks
On Thursday 15 April 2004 13:40, Konstantin Sobolev wrote:
> On Thursday 15 April 2004 11:12, Lenar L?hmus wrote:
> > >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.
> >
> > 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.
>
> 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.
--
vda
Denis Vlasenko wrote:
>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
On Thursday 15 April 2004 16:37, Denis Vlasenko wrote:
> > /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.
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
>
> 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
--
/KoS
* A fool and his money are my kind of customer.
On Thursday 15 April 2004 16:02, Justin Cormack wrote:
> 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.
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
--
/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
On Thu, 2004-04-15 at 14:34, Konstantin Sobolev wrote:
> On Thursday 15 April 2004 16:02, Justin Cormack wrote:
> > 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.
>
> 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
On Thursday 15 April 2004 18:00, Justin Cormack wrote:
> 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...
Attached are files for 2.6.5-mm5 with highmem, ACPI and APIC turned off.
--
/KoS
* Are you into transmogrification, too?
On Thu, 2004-04-15 at 15:26, Konstantin Sobolev wrote:
> On Thursday 15 April 2004 18:00, Justin Cormack wrote:
> > 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...
>
> 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
On Thursday 15 April 2004 18:33, Justin Cormack wrote:
> On Thu, 2004-04-15 at 15:26, Konstantin Sobolev wrote:
> > On Thursday 15 April 2004 18:00, Justin Cormack wrote:
> > > 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...
> >
> > 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!
Konstantin Sobolev wrote:
> On Thursday 15 April 2004 18:33, Justin Cormack wrote:
>
>>On Thu, 2004-04-15 at 15:26, Konstantin Sobolev wrote:
>>
>>>On Thursday 15 April 2004 18:00, Justin Cormack wrote:
>>>
>>>>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...
>>>
>>>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]
> 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
>
> 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/
On Thursday 15 April 2004 15:57, Lenar L?hmus wrote:
> Denis Vlasenko wrote:
> >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
On Thursday 15 April 2004 17:48, Konstantin Sobolev wrote:
> On Thursday 15 April 2004 18:33, Justin Cormack wrote:
> > On Thu, 2004-04-15 at 15:26, Konstantin Sobolev wrote:
> > > On Thursday 15 April 2004 18:00, Justin Cormack wrote:
> > > > 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...
> > >
> > > 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?
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!
> 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.
...
> /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.
> * Did you receive a proper socialist education?
Only half of it ;-)
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Thursday 15 April 2004 23:50, Pavel Machek wrote:
> > /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.
well.. taking into account it's price and final 68MB/sec I've got after
following Justin's advice.. :)
--
/KoS
* Jeez, if you love Honkus...
Ryan Geoffrey Bourgeois wrote:
>>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/
>
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
>
> 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/
Simon Koch wrote:
> Ryan Geoffrey Bourgeois wrote:
>> 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
Denis Vlasenko wrote:
> On Thursday 15 April 2004 17:48, Konstantin Sobolev wrote:
>
>>On Thursday 15 April 2004 18:33, Justin Cormack wrote:
>>
>>>On Thu, 2004-04-15 at 15:26, Konstantin Sobolev wrote:
>>>
>>>>On Thursday 15 April 2004 18:00, Justin Cormack wrote:
>>>>
>>>>>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...
>>>>
>>>>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?
>
>
> 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
On Friday 16 April 2004 04:05, Jeff Garzik wrote:
> Denis Vlasenko wrote:
> > On Thursday 15 April 2004 17:48, Konstantin Sobolev wrote:
> >>On Thursday 15 April 2004 18:33, Justin Cormack wrote:
> >>>On Thu, 2004-04-15 at 15:26, Konstantin Sobolev wrote:
> >>>>On Thursday 15 April 2004 18:00, Justin Cormack wrote:
> >>>>>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...
> >>>>
> >>>>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?
> >
> > 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.
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
On Friday 16 April 2004 18:48, Denis Vlasenko wrote:
> > 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?
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
--
/KoS
* yas eh d'tahW. ??mih raeh uoy diD
Denis Vlasenko wrote:
> On Friday 16 April 2004 04:05, Jeff Garzik wrote:
>>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.
>
>
> 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.02
sata_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.
> 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]
> 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
Henrik Gustafsson wrote:
> [cut]
>
>> 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
Jeff Garzik wrote:
> Denis Vlasenko wrote:
>
>> On Thursday 15 April 2004 17:48, Konstantin Sobolev wrote:
>>
>>> On Thursday 15 April 2004 18:33, Justin Cormack wrote:
>>>
>>>> On Thu, 2004-04-15 at 15:26, Konstantin Sobolev wrote:
>>>>
>>>>> On Thursday 15 April 2004 18:00, Justin Cormack wrote:
>>>>>
>>>>>> 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...
>>>>>
>>>>>
>>>>> 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]
>>> 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.
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