From: Stan Hoeppner on
I have a new single platter 7200rpm 500GB WD SATA drive connected to a
new SiI3512 based PCI card (yes, 33Mhz PCI). Host is a headless server,
dual ~500MHz Intel Mendocino CPUs, 384MB PC100, kernel 2.6.31.1 compiled
by me from kernel.org sources _the Debian way_, very low system load,
over half RAM free at all times, swap never gets touched.

All of my online reading about this drives suggests it's average read
performance is ~100MB/s, low is in the high 80s, and high is 126. I
think most of that published testing is done on Windows. I would think
hdparm results should be similar, and mine are far below what's being
reported my the online tech magazines.

I guess my first question is, why is the performance going through the
Linux system cache buffers ~40% lower than doing a --direct read? Going
through the Linux buffers is normal system operation. Second question
is how do I improve buffered performance? Third, why is the sata_sil
driver defaulting to UDMA/100 instead of UDMA/133, even after
identifying the capability of the drive as UDMA/133? Does this matter?
Is this slowing things down? Last question is, is the
kernel/controller/drive already running at optimal performance, and I'm
misreading reality?

Any informed advice and/or suggestions would be most welcome. Relevant
data follows.

TIA,

Stan


SCSI subsystem initialized
libata version 3.00 loaded.
....
sata_sil 0000:00:11.0: version 2.4
sata_sil 0000:00:11.0: PCI->APIC IRQ transform: INT A -> IRQ 19
scsi0 : sata_sil
scsi1 : sata_sil
ata1: SATA max UDMA/100 mmio m512(a)0xe9610000 tf 0xe9610080 irq 19
ata2: SATA max UDMA/100 mmio m512(a)0xe9610000 tf 0xe96100c0 irq 19
....
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATA-8: WDC WD5000AAKS-00V1A0, 05.01D05, max UDMA/133
ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access ATA WDC WD5000AAKS-0 05.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 sda3 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
ata2: SATA link down (SStatus 0 SControl 310)


greer:/# hdparm -i /dev/sda

/dev/sda:

Model=WDC WD5000AAKS-00V1A0 , FwRev=05.01D05,
SerialNo= WD-WMAWF0431883
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7


greer:/# hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 238 MB in 2.01 seconds = 118.48 MB/sec
Timing buffered disk reads: 160 MB in 3.02 seconds = 52.92 MB/sec

greer:/# hdparm -t --direct /dev/sda

/dev/sda:
Timing O_DIRECT disk reads: 238 MB in 3.02 seconds = 78.86 MB/sec


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Klistvud on
Dne, 12. 12. 2009 07:14:28 je Stan Hoeppner napisal(a):

>
> I guess my first question is, why is the performance going through
> the
> Linux system cache buffers ~40% lower than doing a --direct read?
> Going
> through the Linux buffers is normal system operation. Second
> question
> is how do I improve buffered performance? Third, why is the sata_sil
> driver defaulting to UDMA/100 instead of UDMA/133, even after
> identifying the capability of the drive as UDMA/133?

I would think UDMA/100 is the upper limit of your SATA controller, so
your actual drive gets limited to UDMA5, although it's capable of
UDMA6:

> UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma6


> Does this
> matter?

Yes, it does matter. And is probably at least *one* of the answers to
your first two questions.

> Is this slowing things down? Last question is, is the
> kernel/controller/drive already running at optimal performance, and
> I'm
> misreading reality?

It's most definitely slowing things down. Of course, I may be
misreading reality, as you aptly put it ;)


--
Regards,

Klistvud
Certifiable Loonix User #481801
http://bufferoverflow.tiddlyspot.com


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org