From: Derek Taubert <taubert@geeks.org>
To: htejun@gmail.com, linux-ide@vger.kernel.org
Cc: taubert@geeks.org
Subject: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
Date: Mon, 28 Aug 2006 16:01:32 -0700 [thread overview]
Message-ID: <20060828230132.GB20189@geeks.org> (raw)
Greetings!
I'm using a 2.6.17.4 kernel (straight from kernel.org) patched with
libata-tj-stable-2.6.17.4-20060710 in an effort to make use of an external
drive bay with a Silicon Image port multipler and a bunch of SATA/PATA
drives. For the most part, it's a success (more below) but the write
performance that I'm seeing to a new Seagate 750GB drive (with NCQ) is
terrible (on the order of 1.2MBytes/sec).
The host is an old Toshiba laptop (PIIX4 based) with a 550MHz Celeron
processor. The SATA host interface is a PCMCIA based Silicon Image 3124
chip plugged into the Yenta PCMCIA controller. A tulip based Linksys
10/100 card takes up the other slot. From dmesg:
ACPI: PCI Interrupt 0000:00:04.1[B] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
Yenta: CardBus bridge found at 0000:00:04.1 [1179:ff00]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:04.1, mfunc 0x000c1722, devctl 0x66
usb 1-1: configuration #1 chosen from 1 choice
Yenta: ISA IRQ mask 0x0838, PCI irq 10
Socket status: 30000020
pccard: CardBus card inserted into slot 0
pccard: CardBus card inserted into slot 1
st: Version 20050830, fixed bufsize 32768, s/g segs 256
Adding 248996k swap on /dev/hda2. Priority:42 extents:1 across:248996k
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Linux Tulip driver version 1.1.13-NAPI (May 11, 2002)
PCI: Enabling device 0000:02:00.0 (0000 -> 0003)
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:02:00.0 to 64
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0: MII transceiver #0 config 3000 status 7829 advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 00011400, 00:E0:98:04:21:54, IRQ 10.
libata version 2.00 loaded.
sata_sil24 0000:06:00.0: version 0.3
PCI: Enabling device 0000:06:00.0 (0080 -> 0083)
ACPI: PCI Interrupt 0000:06:00.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:06:00.0 to 64
ata1: SATA max UDMA/100 cmd 0xC8CB0000 ctl 0x0 bmdma 0x0 irq 10
ata2: SATA max UDMA/100 cmd 0xC8CB2000 ctl 0x0 bmdma 0x0 irq 10
ata3: SATA max UDMA/100 cmd 0xC8CB4000 ctl 0x0 bmdma 0x0 irq 10
ata4: SATA max UDMA/100 cmd 0xC8CB6000 ctl 0x0 bmdma 0x0 irq 10
scsi0 : sata_sil24
ata1: SATA link down (SStatus 0 SControl 300)
scsi1 : sata_sil24
ata2: SATA link down (SStatus 0 SControl 300)
scsi2 : sata_sil24
ata3: SATA link down (SStatus 0 SControl 300)
scsi3 : sata_sil24
ata4: SATA link down (SStatus 0 SControl 300)
The /var/log/messages output after hotplugging the multiplier. Note the
NCQ for ata1.00:
Aug 27 18:48:26 linux-srv kernel: ata1: soft resetting port
Aug 27 18:48:26 linux-srv kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 18:48:26 linux-srv kernel: ata1.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 5 ports, feat 0x9/0x9
Aug 27 18:48:27 linux-srv kernel: ata1.00: hard resetting port
Aug 27 18:48:29 linux-srv kernel: ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Aug 27 18:48:29 linux-srv kernel: ata1.01: hard resetting port
Aug 27 18:48:30 linux-srv kernel: ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 18:48:30 linux-srv kernel: ata1.02: hard resetting port
Aug 27 18:48:31 linux-srv kernel: ata1.02: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 18:48:31 linux-srv kernel: ata1.03: hard resetting port
Aug 27 18:48:31 linux-srv kernel: ata1.03: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 18:48:31 linux-srv kernel: ata1.04: hard resetting port
Aug 27 18:48:32 linux-srv kernel: ata1.04: SATA link down (SStatus 0 SControl 300)
Aug 27 18:48:32 linux-srv kernel: ata1.00: ATA-7, max UDMA/133, 1465149168 sectors: LBA48 NCQ (depth 31/32)
Aug 27 18:48:32 linux-srv kernel: ata1.00: configured for UDMA/100
Aug 27 18:48:32 linux-srv kernel: ata1.01: ATA-7, max UDMA/133, 490234752 sectors: LBA48
Aug 27 18:48:32 linux-srv kernel: ata1.01: ata1: dev 0 multi count 0
Aug 27 18:48:32 linux-srv kernel: ata1.01: applying bridge limits
Aug 27 18:48:32 linux-srv kernel: ata1.01: configured for UDMA/100
Aug 27 18:48:32 linux-srv kernel: ata1.02: ATA-6, max UDMA/100, 488397168 sectors: LBA48
Aug 27 18:48:32 linux-srv kernel: ata1.02: ata1: dev 0 multi count 0
Aug 27 18:48:32 linux-srv kernel: ata1.02: applying bridge limits
Aug 27 18:48:32 linux-srv kernel: ata1.02: configured for UDMA/100
Aug 27 18:48:32 linux-srv kernel: ata1.03: ATA-6, max UDMA/100, 488397168 sectors: LBA48
Aug 27 18:48:32 linux-srv kernel: ata1.03: ata1: dev 0 multi count 0
Aug 27 18:48:32 linux-srv kernel: ata1.03: applying bridge limits
Aug 27 18:48:32 linux-srv kernel: ata1.03: configured for UDMA/100
Aug 27 18:48:32 linux-srv kernel: ata1: EH complete
Aug 27 18:48:32 linux-srv kernel: Vendor: ATA Model: ST3750640AS Rev: 3.AA
Aug 27 18:48:32 linux-srv kernel: Type: Direct-Access ANSI SCSI revision: 05
Aug 27 18:48:32 linux-srv kernel: SCSI device sda: 1465149168 512-byte hdwr sectors (750156 MB)
Aug 27 18:48:32 linux-srv kernel: sda: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sda: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sda: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: SCSI device sda: 1465149168 512-byte hdwr sectors (750156 MB)
Aug 27 18:48:32 linux-srv kernel: sda: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sda: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sda: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: sda: sda1
Aug 27 18:48:32 linux-srv kernel: sd 0:0:0:0: Attached scsi disk sda
Aug 27 18:48:32 linux-srv kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Aug 27 18:48:32 linux-srv kernel: Vendor: ATA Model: Maxtor 6Y250P0 Rev: YAR4
Aug 27 18:48:32 linux-srv kernel: Type: Direct-Access ANSI SCSI revision: 05
Aug 27 18:48:32 linux-srv kernel: SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB)
Aug 27 18:48:32 linux-srv kernel: sdb: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdb: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdb: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB)
Aug 27 18:48:32 linux-srv kernel: sdb: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdb: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdb: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: sdb: sdb1
Aug 27 18:48:32 linux-srv kernel: sd 0:0:1:0: Attached scsi disk sdb
Aug 27 18:48:32 linux-srv kernel: sd 0:0:1:0: Attached scsi generic sg1 type 0
Aug 27 18:48:32 linux-srv kernel: Vendor: ATA Model: WDC WD2500BB-00G Rev: 08.0
Aug 27 18:48:32 linux-srv kernel: Type: Direct-Access ANSI SCSI revision: 05
Aug 27 18:48:32 linux-srv kernel: SCSI device sdc: 488397168 512-byte hdwr sectors (250059 MB)
Aug 27 18:48:32 linux-srv kernel: sdc: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdc: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdc: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: SCSI device sdc: 488397168 512-byte hdwr sectors (250059 MB)
Aug 27 18:48:32 linux-srv kernel: sdc: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdc: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdc: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: sdc: sdc1
Aug 27 18:48:32 linux-srv kernel: sd 0:0:2:0: Attached scsi disk sdc
Aug 27 18:48:32 linux-srv kernel: sd 0:0:2:0: Attached scsi generic sg2 type 0
Aug 27 18:48:32 linux-srv kernel: Vendor: ATA Model: WDC WD2500JB-00G Rev: 08.0
Aug 27 18:48:32 linux-srv kernel: Type: Direct-Access ANSI SCSI revision: 05
Aug 27 18:48:32 linux-srv kernel: SCSI device sdd: 488397168 512-byte hdwr sectors (250059 MB)
Aug 27 18:48:32 linux-srv kernel: sdd: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdd: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdd: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: SCSI device sdd: 488397168 512-byte hdwr sectors (250059 MB)
Aug 27 18:48:32 linux-srv kernel: sdd: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdd: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdd: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: sdd: sdd1
Aug 27 18:48:32 linux-srv kernel: sd 0:0:3:0: Attached scsi disk sdd
Aug 27 18:48:32 linux-srv kernel: sd 0:0:3:0: Attached scsi generic sg3 type 0
Aug 27 18:48:33 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16227]: new block device /block/sda
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16437]: new block device /block/sdb
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16467]: new block device /block/sdd
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16487]: new block device /block/sdc
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16587]: new block device /block/sdc/sdc1
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16599]: new block device /block/sdd/sdd1
Aug 27 18:48:37 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16611]: new block device /block/sdb/sdb1
Aug 27 18:48:38 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16603]: new block device /block/sda/sda1
Aug 27 18:49:01 linux-srv hald[9182]: Timed out waiting for hotplug event 1950. Rebasing to 1930
What works:
1) Read performance to all 4 drives is ok (40-50 MBytes/sec as reported
by iostat) and stable. I've hammered a read-only software RAID5 spread
across the last 3 drives with no problem.
2) "smartctl -d ata -a" works nicely to all 4 drives.
3) hdparm -S makes the drives spin down when idle as expected.
4) Hotplug seems to work quite well. I'm even able to power down and
remove a drive from the port multiplier while the other 3 are reading
data (during a "e2fsck -f -n /dev/md0").
What doesn't work so well:
1) Writing to sda1.
# dd if=/dev/zero of=/dev/sda1 count=4M
<ctrl-c, then wait 30 seconds>
264205+0 records in
264204+0 records out
135272448 bytes (135 MB) copied, 111.373 seconds, 1.2 MB/s
>From iostat -k 10:
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 2428.64 2422.46 667.66 24273 6690
sda 36.84 23.72 1667.87 237 16662
sda 2440.60 2434.90 616.00 24349 6160
The read rate is curious (should be 0)...
Top shows 1% user, 3% system, 93% wait.
If I "cat /proc/scsi/sg/devices" during this test, the next to last column
seems to indicate that the queue fills up and pretty much stays that way:
# cat /proc/scsi/sg/devices
0 0 0 0 0 1 31 0 1
0 0 1 0 0 1 1 0 1
0 0 2 0 0 1 1 0 1
0 0 3 0 0 1 1 0 1
# cat /proc/scsi/sg/devices
0 0 0 0 0 1 31 29 1
0 0 1 0 0 1 1 0 1
0 0 2 0 0 1 1 1 1
0 0 3 0 0 1 1 1 1
# cat /proc/scsi/sg/devices
0 0 0 0 0 1 31 31 1
0 0 1 0 0 1 1 0 1
0 0 2 0 0 1 1 0 1
0 0 3 0 0 1 1 0 1
# cat /proc/scsi/sg/devices
0 0 0 0 0 1 31 30 1
0 0 1 0 0 1 1 0 1
0 0 2 0 0 1 1 1 1
0 0 3 0 0 1 1 0 1
2) hdparm -C for all 4 drives always shows "drive state is: standby"
even when I'm certain that the drives are active.
I'd really like some assistance debugging the write performance issue.
The "hdparm -C" issue would be gravy...
Thanks,
Derek
next reply other threads:[~2006-08-28 23:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-28 23:01 Derek Taubert [this message]
2006-08-29 2:39 ` Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive Tejun Heo
2006-08-29 4:58 ` Derek Taubert
2006-08-29 7:54 ` Derek Taubert
2006-08-29 13:35 ` Tejun Heo
2006-08-29 13:27 ` Tejun Heo
2006-08-29 16:44 ` Derek Taubert
2006-08-29 21:24 ` Jeff Garzik
2006-09-01 13:32 ` Tejun Heo
2006-09-01 17:24 ` Derek Taubert
2006-09-02 5:34 ` Derek Taubert
2006-09-03 6:26 ` Derek Taubert
2006-09-03 19:03 ` Tejun Heo
2006-09-03 20:04 ` Derek Taubert
2006-09-28 22:07 ` Derek Taubert
2006-08-29 14:07 ` Greg Freemyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060828230132.GB20189@geeks.org \
--to=taubert@geeks.org \
--cc=htejun@gmail.com \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).