poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Chmielewski]

I have a Silicon Image SIL3112A SATA PCI controller + 2x 200GB, 8MB
Barracuda drives.

The performance under 2.6 kernels is *very* poor (Timing buffered disk
reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
buffered disk reads around 60 MB/sec).



Below three hdparm reads on three different liveCDs (kernels 2.6.11.6,
2.4.28, 2.6.11).


Kernel 2.6.11.6, Slax 5.0.1

root@slax:~# hdparm -Tt /dev/sda /dev/sdb

/dev/sda:
  Timing cached reads:   1124 MB in  2.00 seconds = 560.68 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
  Timing buffered disk reads:   60 MB in  3.10 seconds =  19.38 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device

/dev/sdb:
  Timing cached reads:   1128 MB in  2.00 seconds = 563.80 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
  Timing buffered disk reads:   60 MB in  3.09 seconds =  19.39 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device


Kernel 2.4.28, Slax 4.1.4

root@slax:~# hdparm -Tt /dev/sda /dev/sdb

/dev/sda:
  Timing buffer-cache reads:   1152 MB in  2.00 seconds = 576.00 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported
  Timing buffered disk reads:  180 MB in  3.01 seconds =  59.80 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported

/dev/sdb:
  Timing buffer-cache reads:   1124 MB in  2.00 seconds = 562.00 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported
  Timing buffered disk reads:  180 MB in  3.07 seconds =  58.63 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported


Kernel 2.6.11, Knoppix 3.8.1:

# hdparm -Tt /dev/sda /dev/sdb

/dev/sda:
  Timing cached reads:   1188 MB in  2.00 seconds = 592.61 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
  Timing buffered disk reads:   50 MB in  3.09 seconds =  16.19 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device

/dev/sdb:
  Timing cached reads:   1176 MB in  2.00 seconds = 586.92 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
  Timing buffered disk reads:   54 MB in  3.19 seconds =  16.94 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device



I tested it also with Mandrake 10.2 (it is shipped with 2.6.11 kernel): 
  Timing cached reads was about 100 MB/sec and Timing buffered disk 
reads was about 10 MB/sec.

Another test on Mandrake with 2.6.8.1 kernel - it's the fastest of all 
tests:

# hdparm -Tt /dev/sda

/dev/sda:
  Timing cached reads:   1064 MB in  2.00 seconds = 531.81 MB/sec
BLKFLSBUF failed: Operation not supported
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not 
supported
  Timing buffered disk reads:  310 MB in  3.02 seconds = 102.49 MB/sec


So on three distros with 2.6.11.x kernels (Knoppix, Slax, Mandrake), 
SATA performance was extremely bad for me.
Coincidence, or something SATA-related got borked in 2.6.11?


Tomek

poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Chmielewski]

I have a Silicon Image SIL3112A SATA PCI controller + 2x 200GB, 8MB
Barracuda drives.

The performance under 2.6 kernels is *very* poor (Timing buffered disk
reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
buffered disk reads around 60 MB/sec).



Below three hdparm reads on three different liveCDs (kernels 2.6.11.6,
2.4.28, 2.6.11).


Kernel 2.6.11.6, Slax 5.0.1

root@slax:~# hdparm -Tt /dev/sda /dev/sdb

/dev/sda:
  Timing cached reads:   1124 MB in  2.00 seconds = 560.68 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
  Timing buffered disk reads:   60 MB in  3.10 seconds =  19.38 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device

/dev/sdb:
  Timing cached reads:   1128 MB in  2.00 seconds = 563.80 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
  Timing buffered disk reads:   60 MB in  3.09 seconds =  19.39 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device


Kernel 2.4.28, Slax 4.1.4

root@slax:~# hdparm -Tt /dev/sda /dev/sdb

/dev/sda:
  Timing buffer-cache reads:   1152 MB in  2.00 seconds = 576.00 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported
  Timing buffered disk reads:  180 MB in  3.01 seconds =  59.80 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported

/dev/sdb:
  Timing buffer-cache reads:   1124 MB in  2.00 seconds = 562.00 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported
  Timing buffered disk reads:  180 MB in  3.07 seconds =  58.63 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported


Kernel 2.6.11, Knoppix 3.8.1:

# hdparm -Tt /dev/sda /dev/sdb

/dev/sda:
  Timing cached reads:   1188 MB in  2.00 seconds = 592.61 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
  Timing buffered disk reads:   50 MB in  3.09 seconds =  16.19 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device

/dev/sdb:
  Timing cached reads:   1176 MB in  2.00 seconds = 586.92 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
  Timing buffered disk reads:   54 MB in  3.19 seconds =  16.94 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device



I tested it also with Mandrake 10.2 (it is shipped with 2.6.11 kernel): 
  Timing cached reads was about 100 MB/sec and Timing buffered disk 
reads was about 10 MB/sec.

Another test on Mandrake with 2.6.8.1 kernel - it's the fastest of all 
test:

# hdparm -Tt /dev/sda

/dev/sda:
  Timing cached reads:   1064 MB in  2.00 seconds = 531.81 MB/sec
BLKFLSBUF failed: Operation not supported
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not 
supported
  Timing buffered disk reads:  310 MB in  3.02 seconds = 102.49 MB/sec


So on three distros with 2.6.11.x kernels (Knoppix, Slax, Mandrake), 
SATA performance was extremely bad for me.
Coincidence, or something SATA-related got borked in 2.6.11?


Tomek

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Torcz]

On Thu, Apr 14, 2005 at 06:23:30PM +0200, Tomasz Chmielewski wrote:
> I have a Silicon Image SIL3112A SATA PCI controller + 2x 200GB, 8MB
> Barracuda drives.

 Bad combination.
 
> The performance under 2.6 kernels is *very* poor (Timing buffered disk
> reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
> buffered disk reads around 60 MB/sec).

 2.4 risk data corruption. 2.6 sata_sil.c contains blacklist for some
driver-controller combination.

 See: http://home-tj.org/m15w/

-- 
Tomasz Torcz                        To co nierealne - tutaj jest normalne.
zdzichu@irc.-nie.spam-.pl          Ziomale na życie mają tu patenty specjalne.

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Chmielewski]

Tomasz Torcz wrote:
> On Thu, Apr 14, 2005 at 06:23:30PM +0200, Tomasz Chmielewski wrote:
> 
>>I have a Silicon Image SIL3112A SATA PCI controller + 2x 200GB, 8MB
>>Barracuda drives.
> 
> 
>  Bad combination.

OK, from the link you gave I can see that there might be some problems 
with SIL3112 controller + seagate disks...


>>The performance under 2.6 kernels is *very* poor (Timing buffered disk
>>reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
>>buffered disk reads around 60 MB/sec).
> 
> 
>  2.4 risk data corruption. 2.6 sata_sil.c contains blacklist for some
> driver-controller combination.
> 
>  See: http://home-tj.org/m15w/

...but this link just doesn't explain why performance is sooo bad with 
2.6.11.x kernels (Timing buffered disk reads at 10-20 MB/sec), and is 
just OK with older 2.6 kernels (Timing buffered disk reads even at about 
100 MB/sec with 2.6.8.1).

any clue?

or should I wait for 2.6.11.7 (?), where it should be corrected?


Tomek

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Chris Wright]

* Tomasz Chmielewski (mangoo@interia.pl) wrote:
> or should I wait for 2.6.11.7 (?), where it should be corrected?

Wait, no longer, 2.6.11.7 has been here already ;-)  However, nothing in
this area was touched.  If there's an outstanding issue, please chase it
down, and if it's reasonable regression fix we can consider it for
the -stable tree.

thanks,
-chris

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Chmielewski]

Chris Wright wrote:
> * Tomasz Chmielewski (mangoo@interia.pl) wrote:
> 
>>or should I wait for 2.6.11.7 (?), where it should be corrected?

well, indeed, a week ago or more :)


> Wait, no longer, 2.6.11.7 has been here already ;-)  However, nothing in
> this area was touched.  If there's an outstanding issue, please chase it
> down, and if it's reasonable regression fix we can consider it for
> the -stable tree.

OK so Tomasz Torch suggested that my drive was blacklisted somewhere 
after 2.6.8.1 (it's the last kernel on which I have good performance).

Does drive blacklisting = very poor performance?
And no drive blacklisting = good performance, and possibly data corruption?


Tomek

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Andre Bender]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tomasz Chmielewski wrote:
> 
> OK so Tomasz Torch suggested that my drive was blacklisted somewhere
> after 2.6.8.1 (it's the last kernel on which I have good performance).
> 
> Does drive blacklisting = very poor performance?
> And no drive blacklisting = good performance, and possibly data corruption?
> 

That's what has already been told some posts ago. The kernel developers
don't blacklist anything that works just for fun. There seems to be a
serious problem when combining this pieces of hardware so the
combination is blacklisted to get it working properly but with (much)
less performance.

cu

- --

- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d-(--) s++:-a- c++(++) UL+++(+) P--- L++ ! EW++ !N !o K? w--- O@ M?
V? PS+
PE- Y+ PGP+++ t+ 5++ X++ R+ tv+ b++ DI- D+ Ge+++ hr(-) y+(+)
- ------END GEEK CODE BLOCK------

They say that when you play a Microsoft CD backwards you can hear
demonic voices...
But that's nothing - When you play it forwards it installs Windows

- -------------------------------

My public key can be found at
     http://www.keyserver.net
my fingerprint is
     302C FD91 2CE0 487E E086 EEBC D8D9 2865 E32F 4D56
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCX24m29koZeMvTVYRAharAJ4r4aCCuDNt+B0zjv88tGgOEQIGMACgsVYm
xibnwIYSV+8LUcnXaMImorE=
=NHfy
-----END PGP SIGNATURE-----

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Chmielewski]

Andre Bender wrote:

>>OK so Tomasz Torch suggested that my drive was blacklisted somewhere
>>after 2.6.8.1 (it's the last kernel on which I have good performance).
>>
>>Does drive blacklisting = very poor performance?
>>And no drive blacklisting = good performance, and possibly data corruption?
> 
> 
> That's what has already been told some posts ago. The kernel developers
> don't blacklist anything that works just for fun. There seems to be a
> serious problem when combining this pieces of hardware so the
> combination is blacklisted to get it working properly but with (much)
> less performance.

I see, there were people reporting "drive hangups".
They were reporting it happens quite quickly.

I don't experience those under 2.6.8.1, in which my drive wasn't 
blacklisted yet (it seems it got blacklisted in 2.6.11, see this link
http://www.linuxhq.com/kernel/v2.6/11-rc2-bk6/drivers/scsi/sata_sil.c ).

My setup is SiI 3112 SATA PCI controller, 2x Seagate Barracuda 200 GB, 8 
MB cache, 7200 rpm (Model: ST3200822AS ) connected into one Linux md0 
raid1, ext3 filesystem on md0.

I am running several tests:

1) creating 1 GB file from /dev/zero using dd, then calculating it's 
md5sum (it should always be the same; it stresses drive, too), then 
copying it with a new name, calculating md5sum again - if it doesn't 
match, the script will quit

I run two of these tests in parallel.


2) tar'ring / to a file (so it opens many files), then calculating its 
md5sum (md5sums will differ, but it stresses the drive)


3) copying /dev/hda1 partition (which is 800 megs big on an IDE disk) to
Seagate SATA drives, then calculating it's md5sum (which should be 
always the same, as /dev/hda1 is not used)


4) rsyncing / to /root/test4, then removing it - so it opens many files 
and creates many, too.


These 4 tests are running simultaneously, each in a loop.
I believe it is quite stressing for the drives.

So far no hangup, weird system log, etc. unexpected behaviour.
It's 4 hours they are running now, I know it's not much, but people 
reported almost instant hangups.

Or perhaps my "tests" are wrong?


# cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
   Vendor: ATA      Model: ST3200822AS      Rev: 3.01
   Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
   Vendor: ATA      Model: ST3200822AS      Rev: 3.01
   Type:   Direct-Access                    ANSI SCSI revision: 05


# lspci -vv (for SiI 3112 SATA PCI controller):

02:09.0 Unknown mass storage controller: Silicon Image, Inc. (formerly 
CMD Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller 
(rev 02)
         Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) 
SiI 3112 SATALink Controller
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium 
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Latency: 64, cache line size 08
         Interrupt: pin A routed to IRQ 11
         Region 0: I/O ports at 4800 [size=8]
         Region 1: I/O ports at 4400 [size=4]
         Region 2: I/O ports at 4000 [size=8]
         Region 3: I/O ports at 3c00 [size=4]
         Region 4: I/O ports at 3800 [size=16]
         Region 5: Memory at d0101400 (32-bit, non-prefetchable) [size=512]
         Expansion ROM at <unassigned> [disabled] [size=512K]
         Capabilities: [60] Power Management version 2
                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=2 PME-


Tomek

----------------------------------------------------------------------
Startuj z INTERIA.PL! >>> http://link.interia.pl/f186c 

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Torcz]

On Fri, Apr 15, 2005 at 12:08:15AM +0200, Tomasz Chmielewski wrote:
> >>The performance under 2.6 kernels is *very* poor (Timing buffered disk
> >>reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
> >>buffered disk reads around 60 MB/sec).
> >
> >
> > 2.4 risk data corruption. 2.6 sata_sil.c contains blacklist for some
> >driver-controller combination.
> >
> > See: http://home-tj.org/m15w/
> 
> ...but this link just doesn't explain why performance is sooo bad with 
> 2.6.11.x kernels (Timing buffered disk reads at 10-20 MB/sec), and is 
> just OK with older 2.6 kernels (Timing buffered disk reads even at about 
> 100 MB/sec with 2.6.8.1).
> 
> any clue?

 The sata_sil blacklist grown over time. Older version didn't mark your
drive as bad. Check sata_sil history at
http://www.linuxhq.com/kernel/file/drivers/scsi/sata_sil.c ,
you may find exact time when your drive got blacklisted.

-- 
Tomasz Torcz                        To co nierealne - tutaj jest normalne.
zdzichu@irc.-nie.spam-.pl          Ziomale na życie mają tu patenty specjalne.

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Chmielewski]

Tomasz Torcz wrote:

>>>See: http://home-tj.org/m15w/
>>
>>...but this link just doesn't explain why performance is sooo bad with 
>>2.6.11.x kernels (Timing buffered disk reads at 10-20 MB/sec), and is 
>>just OK with older 2.6 kernels (Timing buffered disk reads even at about 
>>100 MB/sec with 2.6.8.1).
>>
>>any clue?
> 
> 
>  The sata_sil blacklist grown over time. Older version didn't mark your
> drive as bad. Check sata_sil history at
> http://www.linuxhq.com/kernel/file/drivers/scsi/sata_sil.c ,
> you may find exact time when your drive got blacklisted.

OK thanks, I'll look for that.

What is this blacklisting really (besides that it gives bad performance 
for me)?

Does it mean that if I use a kernel which performs well on this hardware 
(i.e. 2.6.8.1, does not seem to have this blacklisting enabled yet) I 
risk data corruption?

And on a kernel in which my hardware is blacklisted, and therefore which 
performs poorly, I don't risk data corruption (at least when it comes to 
transferring data between the drive and the SATA controller)?


Tomek