# SSD Sata2 help, slow performance? [SOLVED]

## petlab

I bought a Patriot 64GB SSD v.2 and I am not getting the bandwidth I expect, and I think my controller may be the problem.  I am getting reads at around 75MB/S according to hdparm, bonnie++ says about 88MB with 18%cpu.

I am not expecting the 175/100 read/write as specified by Patriot, but I was hoping to get above 100 reads with this setup.

```
Hardware and Software

AMD AthlonXP 2800, with 1.5GB RAM at 333

Linux 2.6.28-hardened #2 PREEMPT Thu Feb 5 12:50:09 PST 2009 i686 AMD Athlon(tm) XP 2800+ AuthenticAMD GNU/Linux

Promise Mass storage controller [0180]: PDC40718 (SATA 300 TX4) [105a:3d17] (rev 02) (sata2)

sata_promise

bonnie++, hdparm
```

Some relevant dmesg / info:

```
libata version 3.00 loaded.

sata_promise 0000:01:0a.0: version 2.12

scsi0 : sata_promise

ata1: SATA max UDMA/133 mmio m4096@0xe9028000 ata 0xe9028380 irq 16

ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

ata1.00: ATA-8: PATRIOT MEMORY 64GB SSD, 02.10104, max UDMA/100

ata1.00: 125206528 sectors, multi 0: LBA

ata1.00: configured for UDMA/100

csi 0:0:0:0: Direct-Access     ATA      PATRIOT MEMORY 6 02.1 PQ: 0 ANSI: 5

sd 0:0:0:0: Attached scsi generic sg0 type 0
```

hdparm -vI /dev/sda

```

/dev/sda:

 IO_support    =  0 (default)

 readonly      =  0 (off)

 readahead     = 256 (on)

 geometry      = 7793/255/63, sectors = 125206528, start = 0

ATA device, with non-removable media

        Model Number:       PATRIOT MEMORY 64GB SSD

        Serial Number:      MK0C08490DAD30010

        Firmware Revision:  02.10104

Standards:

        Used: ATA/ATAPI-7 T13 1532D revision 4a

        Supported: 8 7 6 5 & some of 8

[snip]

        cache/buffer size  = unknown

Capabilities:

        LBA, IORDY(can be disabled)

        Standby timer values: spec'd by Standard, no device specific minimum

        R/W multiple sector transfer: Max = 1   Current = ?

        Recommended acoustic management value: 128, current value: 254

        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    SMART feature set

           *    Power Management feature set

                Write cache

                Look-ahead

           *    Mandatory FLUSH_CACHE

           *    SATA-I signaling speed (1.5Gb/s)

           *    SATA-II signaling speed (3.0Gb/s)

           *    Host-initiated interface power management

           *    Phy event counters

Checksum: correct
```

I see that hdparm thinks the drive can do udma5, which is 100MB/s right?  What's the difference between that, and where I read

```
Standards:

        Used: ATA/ATAPI-7 T13 1532D revision 4a

        Supported: 8 7 6 5 & some of 8
```

And how does that compare with the manufacturer's specified speeds?  I have already tried sdparm:

```
# hdparm -X69 /dev/sda

/dev/sda:

 setting xfermode to 69 (UltraDMA mode5)

 HDIO_DRIVE_CMD(setxfermode) failed: Invalid exchange

```

and get the same error with -X70, -X71.

Erm, so I'm ignorant in several spots here.  Any help on tuning this is appreciated.  AFAIK maybe I don't want udma at all, or the sata_promise driver is .udma_mask-ing me too low.  Or something else IDK.  THanks!

----------

## zyko

Does your controller do ahci && is it enabled in your kernel?

----------

## NeddySeagoon

petlab,

If you believe

```
ata1.00: ATA-8: PATRIOT MEMORY 64GB SSD, 02.10104, max UDMA/100
```

which should be read from the drive, UDMA/100 is the best you can expect.  Thats a peak transfer raite of 100Mb/sec, which you won't see in practice as there will be gaps in the read data for commands and handshaking. 

If your 

```
Promise Mass storage controller [0180]: PDC40718 (SATA 300 TX4) [105a:3d17] (rev 02) (sata2)
```

is plugged into a 33MHz, 32 bit PCI slot and I expect it is, given your CPU, your PCI bus has an available theoretical bandwidth of 133MB/sec for all devices.

You can never achieve that - thats the burst data rate for a single device transferring data. It would be doing well to approach 100Mb/sec

----------

## petlab

zyko: i'm looking into that, to see if it would help.  Neither of these controllers does ahci, afaik.  They are too old.

NeddySeagoon:  Right.  I am trying to figure out what those M$windows people are measuring.  Using different benchmarks, they show "measurement" graphs with this drive doing 175MB/s sequential reads - somehow.  Also the Intel X25s supposedly can do 225MB/s.   With all these 'fast' drives around, I'm trying to see what they're measuring.  It isn't totally fake, IMO.

I think it is supposed to be either burst or sustained THROUGHPUT.  Either would be fine with me.  AFAIK there is no way to measure or advertise 175MB/s sequential reads if a drive can only do udma100.  Neither burst or sustained.  So there is something I still don't know here.  My drive doesn't have a buffer, so it can't be sata bus only measurements.

I have spent ~8 hours surfing for a quick answer, but it seems to be a hole in cyberspace.  Lots of people linking to t13.org, intel, yadda yadda.  I need the end-user answer, not the 10k pages of specs.  After a while, if nobody answers, I'm going to bother Jeff Garzik(?) and ask what "225MB/s" means.

I am aware of the general lack of knowledge around bus speed, thruput, dma, etc., and don't need to talk those over.  We'll see what is faster than udma6 and beyond.

I'll let us know what I find out.

----------

## NeddySeagoon

petlab,

I was trying to make two points.

1. The drive may or may not do better than the 100Mb/sec

2. Your PCI card won't let you go any faster anyway.

To go faster, you need a SATA2 controller on the motherboard or in a PCIe or PCIx slot.

----------

## petlab

NeddySeagoon:  If I seemed rude, I apoligize. I wasn't meaning to be curt.  I agree with 1. and 2.  It seems the PCI slot is running at 66MHz, so possibly it could transfer what, like 233MB/s theoretical.  I know that isn't real-world.

Here is the part that doesn't make sense:  My friend has this same drive, on a much faster machine.  Using bonnie++ I show sequential reads between 72 and 91 MB/s.  Wow!  But his system reads 139MB/s!

I don't understand how udma5 (100) could do that.  I'd like to know why the speeds can be above 100.  I figure bonnie++ is relatively accurate, so hmmm.  Still learning here.  I have a post on Patriotmemory.com asking about this, hopefully I will get a response Monday.  I will check my friend's drive too, to see what it reports for udma.

Thanks again for your interest and help,  I hope to make this clearer for all.

petlab

----------

## NeddySeagoon

petlab,

Its not rude - there is nothing to apologise for.

I'm not sure I believe the 

```
ata1.00: ATA-8: PATRIOT MEMORY 64GB SSD, 02.10104, max UDMA/100
```

reported by the drive.

Its SATA ... UDMA s a PATA standard.

Post your

```
lspci -vv
```

output. A very few server motherboards had 66MHz 64 bit PCI slots but they were both rare and expensive

Your lspci will show that, as well as what else is on the PCI bus the drive is sharing with.

If you have an on board SATA port, even SATA1, try that. It it likely to be faster than a PCI slot because it is not limited to the PCI bus speed. The SATA chip can be on a faster 'on board' bus and often is. You may need to jumper the drive so it falls back to SATA1 link speeds properly. Its supposed to happen automatically but many drives have a jumper to force it.

----------

## petlab

I do have onboard sata1 and got the same speeds.  I'm looking at:

```
Status: Cap+ 66MHz+
```

 on both controllers and I think that means they are running at 66.  On this board, they both sit on the PCI bus anyway.

I will look back into PCI latency as well.  That may help. I looked at NCQ, but it looks like no-go for this drive.  I looked at dmesg and the drive doesn't claim to support it.  I did a bunch of reading on http://linux-ata.org and that was really informative.

```
george ykill # lspci -vvv -s 1:9

01:09.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02)

        Subsystem: Promise Technology, Inc. PDC40718 (SATA 300 TX4)

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes

        Interrupt: pin A routed to IRQ 17

        Region 0: I/O ports at a400 [size=128]

        Region 2: I/O ports at a800 [size=256]

        Region 3: Memory at e9028000 (32-bit, non-prefetchable) [size=4K]

        Region 4: Memory at e9000000 (32-bit, non-prefetchable) [size=128K]

        [virtual] Expansion ROM at 740a0000 [disabled] [size=32K]

        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=0 PME-

        Kernel driver in use: sata_promise

george ykill # lspci -vvv -s 1:a

george ykill # lspci -vvv -s 1:b

01:0b.0 RAID bus controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 01)

        Subsystem: Silicon Image, Inc. SiI 3112 SATARaid Controller

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 32, Cache Line Size: 32 bytes

        Interrupt: pin A routed to IRQ 18

        Region 0: I/O ports at ac00 [size=8]

        Region 1: I/O ports at b000 [size=4]

        Region 2: I/O ports at b400 [size=8]

        Region 3: I/O ports at b800 [size=4]

        Region 4: I/O ports at bc00 [size=16]

        Region 5: Memory at e902a000 (32-bit, non-prefetchable) [size=512]

        [virtual] Expansion ROM at 74000000 [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-

        Kernel driver in use: sata_sil

```

I'll post more around Monday when I get some responses from Patriot.

----------

## petlab

EDIT:

I talked to my friend with the same drive last night, and came to a decision on several points after more some more google study.  I am still largely ignorant in this area, so take this lightly:

UDMA/SATA - They are completely different.  The udma spec defines how PATA drives can transmit data.  Some older controllers can only treat SATA drives as a PATA ones, so this is included as a compatibility feature on some sata drives.  Those older SATA/PATA controllers can only get 100MB/s out of the drive because that's all the controller can do.

SATA/SATAII - The libata drivers, well documented on http://linux-ata.org will handle a drive in true SATA mode, for supported chipsets.  These drivers are then capable of transmitting "full rate," which is either 150MB/s or 300MB/s approximately.  So this is completely different than UDMA-xx.  This is how people can see sequential reads in the range of 250MB/s on Intel X-25 drives.  They aren't using UDMA-anything.

AHCI/SATAx - AHCI is cool because it can do NCQ for drives that support it.  NCQ is a method where requests are resequenced by both the drive and the controller for maximum throughput/ lowest latency.  This is similar to what the kernel does, with the I/O schedulers you may have read about.  A controller with full AHCI support can really improve bandwidth, even for SSDs.  My drive and/or controller don't support AHCI, so I don't have that extra boost.

My sequential read speed vs. my friend's - My system, when in runlevel 2, shows a sequential read speed of 91MB/s.  My system is a 32-bit athlonxp running at 2088MHz.  When I'm in KDE4, with lots of services running, I see only 75MB/s.  My friend's system is a dual socket opteron machine with each chip has 2 cores.  Much faster machine, to say the least.  His bonnie++ output shows 139MB/s for the same drive.  I didn't ask, but I think that was taken with ALL his services running (lots).  So, after checking everything, I found that the speed difference is due not to misconfiguration, but machine speed.

This is good news for me, since it means that the drive is configured properly and it can send data as fast as my poor old machine can ask for it.  It also means it's time for me to get a faster machine...

Thanks for all your input

petlab

----------

