sata_sil24 performance weirdness

sata_sil24 performance weirdness

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

I forward-ported Tejun's PMP patches to libata#upstream (my first attempt at it
a few weeks ago failed, but this round works fine, tested at each branch
stage), and in using them, I have noticed a bit of oddity.

While dmesg claims that 3.0Gbps was negotiated, the combined performance of the
5 disks never exceeds 1.5Gbps, no matter how I combine them. Is something in
the driver overriding the 3Gbps speed bits somewhere?

My SATA enclosure the 5-disk Fusion 500P from Sonnet (PMP 0x1095:0x3726)

Controller:
Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)

Drives:
5x Seagate ST3320620AS (7200.10 320Gbyte)

ata9: SATA max UDMA/133 cmd 0xFFFFC20000070000 ctl 0x0 bmdma 0x0 irq 18
ata10: SATA max UDMA/133 cmd 0xFFFFC20000072000 ctl 0x0 bmdma 0x0 irq 18
scsi10 : sata_sil24
ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata9.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 5 ports, feat 0x9/0x9
ata9.00: hard resetting port
ata9.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata9.01: hard resetting port
ata9.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata9.02: hard resetting port
ata9.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata9.03: hard resetting port
ata9.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata9.04: hard resetting port
ata9.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata9.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
ata9.00: configured for UDMA/133
ata9.01: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
ata9.01: configured for UDMA/133
ata9.02: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
ata9.02: configured for UDMA/133
ata9.03: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
ata9.03: configured for UDMA/133
ata9.04: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
ata9.04: configured for UDMA/133
ata9: EH complete
scsi11 : sata_sil24
ata10: SATA link down (SStatus 0 SControl 300)
scsi 10:0:0:0: Direct-Access     ATA      ST3320620AS      3.AA PQ: 0 ANSI: 5
SCSI device sdi: 625142448 512-byte hdwr sectors (320073 MB)
sdi: Write Protect is off
sdi: Mode Sense: 00 3a 00 00
(rest of the disks sdi-> sdm all brought up in an identical fashion here).

-- 
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

sata_sil24 performance weirdness

[Richard Scobie]

Robin H. Johnson wrote:

 >While dmesg claims that 3.0Gbps was negotiated, the combined 
 >performance of the 5 disks never exceeds 1.5Gbps, no matter how I 
 >combine them. Is something in the driver overriding the 3Gbps speed 
 >bits somewhere?

Perhaps there is a hardware/firmware issue with the Sil3132, as this has 
been reported at a reputable Mac hardware performance site, see:

http://www.barefeats.com/quick.html

The December 23rd entry, "ExpressCard SATA bandwidth woes" mentions 
exactly this issue with an Express card using the Sil3132 and on a 
Sil3132 based SATA Adaptor card.

Regards,

Richard

Re: sata_sil24 performance weirdness

[Tejun Heo]

Robin H. Johnson wrote:
> I forward-ported Tejun's PMP patches to libata#upstream (my first attempt at it
> a few weeks ago failed, but this round works fine, tested at each branch
> stage), and in using them, I have noticed a bit of oddity.

Great, care to share them?

> While dmesg claims that 3.0Gbps was negotiated, the combined performance of the
> 5 disks never exceeds 1.5Gbps, no matter how I combine them. Is something in
> the driver overriding the 3Gbps speed bits somewhere?

Nope.  I'll ask SIMG.

-- 
tejun

Re: sata_sil24 performance weirdness

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

On Thu, Dec 28, 2006 at 12:55:04PM +0900, Tejun Heo wrote:
> Robin H. Johnson wrote:
> > I forward-ported Tejun's PMP patches to libata#upstream (my first attempt at it
> > a few weeks ago failed, but this round works fine, tested at each branch
> > stage), and in using them, I have noticed a bit of oddity.
> 
> Great, care to share them?
I don't have a machine with sufficient bandwidth to host a git, so it's just exported patches.

Complete set here:
http://dev.gentoo.org/~robbat2/libata-development/

Naming convention:
$XX_$BRANCH_$YYYY_$PATCHNAME

XX = branch sequence number
BRANCH = branch name, as used by Tejun in his git repo (hp-poll, vt8251-ahci, link, pmp-prep, pmp)
YYYY = patch sequence number

There are also 5 tarballs, containing all of the patches for that branch.

00_hp-poll_0000ALL.tar.gz
01-vt8251-ahci_0000ALL.tar.gz
02_link_0000ALL.tar.gz
03_pmp-prep_0000ALL.tar.gz
04-pmp_0000ALL.tar.gz

-- 
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]