Possible performance issue with sata_sil og Gigabyte i-Ram

Possible performance issue with sata_sil og Gigabyte i-Ram

[Oddbjørn Kvalsund]

Hi,

I recently purchased a Gigabyte i-Ram GC Ramdisk after reading some
quite impressive reviews online. Getting the card up and running
connected to a ST Lab A-223 Serial ATA PCI Card (sil3114 using sata_sil)
with kernel 2.6.19.1 was quite easy, thanks guys!

Access times on this thing are great, but I seem to be hitting some
strange performance-issues when doing large reads/writes. "hdparm -t
/dev/sda" gives me 80-82 MB/s on average and bonnie++ (see link to
complete output below) confirms these results.  My simple stdio
C-program gives write-speeds of around 70 MB/s.  

Other people using this device report of read/write speeds constantly
maxing out their SATA150 or PCI-bus. Is this my sil3114 being the
bottleneck? Other devices on the PCI-bus? My general system (see link to
the complete output of lspci and /proc/cpuinfo below)? Or is this some
glitch in the iRam + sil3114 combination?

I cannot manually enable DMA on this device, as "hdparm -d1 /dev/sda"
fails with "HDIO_SET_DMA failed: Inappropriate ioctl for device", but
from what I can tell from dmesg (U)DMA should be enabled for this drive.
I have tried enabling UDMA/133 for the controller (in sata_sil.c), giving this
output on boot:

libata version 2.00 loaded.
sata_sil 0000:03:03.0: version 2.0
ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 19 (level, low) -> IRQ 17
ata1: SATA max UDMA/133 cmd 0xD081AC80 ctl 0xD081AC8A bmdma 0xD081AC00 irq 17
ata2: SATA max UDMA/133 cmd 0xD081ACC0 ctl 0xD081ACCA bmdma 0xD081AC08 irq 17
ata3: SATA max UDMA/133 cmd 0xD081AE80 ctl 0xD081AE8A bmdma 0xD081AE00 irq 17
ata4: SATA max UDMA/133 cmd 0xD081AEC0 ctl 0xD081AECA bmdma 0xD081AE08 irq 17
scsi0 : sata_sil
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATA-7, max UDMA/133, 1048319 sectors: LBA 
ata1.00: ata1: dev 0 multi count 16
ata1.00: Drive reports diagnostics failure. This may indicate a drive
ata1.00: fault or invalid emulation. Contact drive vendor for information.
ata1.00: configured for UDMA/133
<snip>
scsi 0:0:0:0: Direct-Access     ATA      GIGABYTE i-RAM   v0.9 PQ: 0 ANSI: 5

...but this makes no noticeable difference from the default UDMA/100 mode.

The test system is a pretty standard desktop computer from a few years back:
CPU: Intel Pentium 4 - 2.4 GHz, 512 KB cache
Mainboard: MSI 845G Max-L
Memory: Apacer 256 MB PC2700
System disk: IBM IC35L040AVER07-0 40 GB 7200 RPM 8.5 MS SEEK TIME 2 MB BUFFER

I'm using the old piix-driver (not libata) for the IBM-disk, as I was
having some problems getting it to work with the libata-driver. I might
try to fix it later on, but could this be what's causing the problems?
The file system is ext3 both on the IBM disk and the i-Ram.  On boot I
get a message saying "The chipset may have PM-Timer Bug". I have tried
setting acpi_pm_good=1 as a kernel parameter, but this made no
difference.

Complete output of dmesg/cpuinfo/bonnie/lspci/hdparm can be found here: 
http://nixx.no/oddbjorn/iram

Could someone please shed some light on this?

I hope I have provided enough information about the relevant hardware,
if not; let me know and I'll post what I can find.

Thanks! :)

-- 
Regards
Oddbjørn Kvalsund

Re: Possible performance issue with sata_sil og Gigabyte i-Ram

[Jeff Garzik]

Oddbjørn Kvalsund wrote:
> Hi,
> 
> I recently purchased a Gigabyte i-Ram GC Ramdisk after reading some
> quite impressive reviews online. Getting the card up and running
> connected to a ST Lab A-223 Serial ATA PCI Card (sil3114 using sata_sil)
> with kernel 2.6.19.1 was quite easy, thanks guys!
> 
> Access times on this thing are great, but I seem to be hitting some
> strange performance-issues when doing large reads/writes. "hdparm -t
> /dev/sda" gives me 80-82 MB/s on average and bonnie++ (see link to
> complete output below) confirms these results.  My simple stdio
> C-program gives write-speeds of around 70 MB/s.  
> 
> Other people using this device report of read/write speeds constantly
> maxing out their SATA150 or PCI-bus. Is this my sil3114 being the
> bottleneck? Other devices on the PCI-bus? My general system (see link to
> the complete output of lspci and /proc/cpuinfo below)? Or is this some
> glitch in the iRam + sil3114 combination?

FWIW, I have nothing but trouble with the gigabyte i-RAM.  I thought it 
was the coolest device in the world, and bought one as soon as I found one.

However, I am unable to keep it from corrupting data.  I primarily use 
it on sil3114, just like your hardware, but I have the same problems 
with other controllers.

My gut feeling is that the i-RAM has very strict RAM model requirements, 
and needs the latest firmware, but I have not yet tested these hypotheses.

I would love to get it working too...

	Jeff

Re: Possible performance issue with sata_sil og Gigabyte i-Ram

[Jeff Garzik]

Alan wrote:
> What sort of problems ? I've got an iRAM here for debugging/testing
> courtesy of a company using them and the one I have seems to pass all the
> testing I've thrown at it.


Out of curiosity, are you using one of the sticks from the [quite 
limited] Gigabyte-approved RAM list?

	Jeff

Re: Possible performance issue with sata_sil og Gigabyte i-Ram

[Alan]

> Other people using this device report of read/write speeds constantly
> maxing out their SATA150 or PCI-bus. Is this my sil3114 being the
> bottleneck? Other devices on the PCI-bus? My general system (see link to

Possibly. 80Mbytes/sec seems to be about all you get from PCI bus with
many machines. Remember the SATA150, UDMA/133 and PCI bus limits are
largely theoretical, especially as most ATA controllers have significant
turn around time between commands and cannot queue.

> from what I can tell from dmesg (U)DMA should be enabled for this drive.
> I have tried enabling UDMA/133 for the controller (in sata_sil.c), giving this
> output on boot:

If you are getting 80Mb/sec then UDMA is enabled 8)

> libata version 2.00 loaded.
> sata_sil 0000:03:03.0: version 2.0
> ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 19 (level, low) -> IRQ 17
> ata1: SATA max UDMA/133 cmd 0xD081AC80 ctl 0xD081AC8A bmdma 0xD081AC00 irq 17
> ata2: SATA max UDMA/133 cmd 0xD081ACC0 ctl 0xD081ACCA bmdma 0xD081AC08 irq 17
> ata3: SATA max UDMA/133 cmd 0xD081AE80 ctl 0xD081AE8A bmdma 0xD081AE00 irq 17
> ata4: SATA max UDMA/133 cmd 0xD081AEC0 ctl 0xD081AECA bmdma 0xD081AE08 irq 17
> scsi0 : sata_sil
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata1.00: ATA-7, max UDMA/133, 1048319 sectors: LBA 
> ata1.00: ata1: dev 0 multi count 16
> ata1.00: Drive reports diagnostics failure. This may indicate a drive
> ata1.00: fault or invalid emulation. Contact drive vendor for information.
> ata1.00: configured for UDMA/133

This looks correct - the diagnostics failure appears to be an i-Ram
firmware bug so we warn about it only.

> I'm using the old piix-driver (not libata) for the IBM-disk, as I was
> having some problems getting it to work with the libata-driver. I might

What sort of problems ? I've got an iRAM here for debugging/testing
courtesy of a company using them and the one I have seems to pass all the
testing I've thrown at it.

Alan

Re: Possible performance issue with sata_sil og Gigabyte i-Ram

[Oddbjørn Kvalsund]

On Tue 23 Jan 23:21, Alan wrote:
> > Other people using this device report of read/write speeds constantly
> > maxing out their SATA150 or PCI-bus. Is this my sil3114 being the
> > bottleneck? Other devices on the PCI-bus? My general system (see link to
> 
> Possibly. 80Mbytes/sec seems to be about all you get from PCI bus with
> many machines. Remember the SATA150, UDMA/133 and PCI bus limits are
> largely theoretical, especially as most ATA controllers have significant
> turn around time between commands and cannot queue.

Ah, alright. I'll try to remove the other cards on the PCI-bus to see if
that makes a difference, if not; well I guess 80 MB/s isn't that bad :)

> > from what I can tell from dmesg (U)DMA should be enabled for this drive.
> > I have tried enabling UDMA/133 for the controller (in sata_sil.c), giving this
> > output on boot:
> 
> If you are getting 80Mb/sec then UDMA is enabled 8)

Good!

> > I'm using the old piix-driver (not libata) for the IBM-disk, as I was
> > having some problems getting it to work with the libata-driver. I might
> 
> What sort of problems ? I've got an iRAM here for debugging/testing
> courtesy of a company using them and the one I have seems to pass all the
> testing I've thrown at it.

Sorry, I was cramming too much information into that sentence.

I was having problems getting the _IBM IDE-disk_, not the i-Ram, working
with the ata_piix. I haven't really dug deep into this, but I suspect
it's probably something silly like the drive changing identifier
(hda -> sda) or something like that.

Do you thing this (using the regular piix-driver for the IBM system disk
and the sata_sil-driver for the i-Ram) could be causing any performance
problems?

-- 
Oddbjørn Kvalsund

Re: Possible performance issue with sata_sil og Gigabyte i-Ram

[Oddbjørn Kvalsund]

On Tue 23 Jan 17:12, Jeff Garzik wrote:
> However, I am unable to keep it from corrupting data.  I primarily use 
> it on sil3114, just like your hardware, but I have the same problems 
> with other controllers.
> 
> My gut feeling is that the i-RAM has very strict RAM model requirements, 
> and needs the latest firmware, but I have not yet tested these hypotheses.

Hm, that's a pity! I have used an Apacer 512 MB PC2700 module in my i-Ram
for testing, but I have ordered two Kingston KVR400X64C3A/1G sticks
that are on Gigabytes list of recommended ram modules[1].

The Apacer module hasn't given my any trouble though. I ran some stress
tests on it last night, bonnie++[2] and stress[3] for a few hours, and
as far as I could tell this didn't screw up the file system in any way.
Do you have any test applications that can reproduce the error on your
i-Ram? I'd be more than happy to do some testing both using my old
Apacer module and the new Kingston modules when they arrive.

With regards to the i-Ram being picky about RAM, check this post:
http://www.nerdnos.net/?newsarchives
According to this guy, the i-Ram does not support high density ram
modules. Could this be what's causing your data/file system corruption?

[1]: http://www.gigabyte.com.tw/Support/Peripherals/FAQ_Model.aspx?FAQID=2152&ProductID=2076
[2]: http://www.coker.com.au/bonnie++/
[3]: http://weather.ou.edu/~apw/projects/stress/

-- 
Oddbjørn Kvalsund