SSD starts fast then slows down on F16

Flintstone · #1 6th July 2012, 05:50 PM

My SSD appears to start fast and after some moderate disk activity (e.g. yum update) it slows down, rebooting fixes it for a while ... any ideas?

Code:

$ cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Wed Feb  8 16:49:34 2012
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=b07965e3-d2f8-42fa-9936-806126679d5e /                       ext4    defaults        1 1
UUID=83f69c4a-470b-4cca-9ab1-4c1716b1f715 /boot                   ext3    defaults        1 2
UUID=b515116a-7b26-406d-b09c-3bd5df96eaff /home                   ext4    defaults        1 2
UUID=e9c37af0-e44d-4006-983a-f35eda3d0cc7 swap                    swap    defaults        0 0

$ sudo hdparm -i /dev/sda

/dev/sda:

 Model=Corsair Force GT, FwRev=1.3.3, SerialNo=1143820800000990000F
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=351651888
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

$ sudo hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads:  54 MB in  4.55 seconds =  11.88 MB/seconds

$ dd bs=1M count=200 if=/dev/zero of=text.data
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 107.284 s, 2.0 MB/s

#2 7th July 2012, 04:50 PM

Do you have the latest firmware?

http://forum.corsair.com/v3/forumdisplay.php?f=206

marko · #3 7th July 2012, 04:59 PM

This has good information:

http://forums.fedoraforum.org/showthread.php?t=256068

it might help to enable TRIM support in your fstab by using the "discard" option on your ext4 filesystems

#4 7th July 2012, 05:40 PM

I would use wiper.sh (to trim) after editing fstab

change the / fstab line to

Code:

UUID=b07965e3-d2f8-42fa-9936-806126679d5e /                       ext4    defaults,discard        1 1

Code:

su -
yum install hdparm wget
wget http://sourceforge.net/projects/hdparm/files/hdparm/hdparm-9.39.tar.gz
tar -xvf hdparm-9.39.tar.gz
init 1
cd /root/hdparm-9.39/wiper
mount -o remount,ro /
./wiper.sh --commit /dev/sda1 #change to the root dev address
reboot

#5 7th July 2012, 05:55 PM

I'm not sure that enabling TRIM will make any difference in this instance, since a reboot apparently fixes the issue temporarily. Also, the read speed is degraded, which would not be helped by enabling TRIM.

Of course, that's not to say it's not advisable to enable TRIM support where possible.

stevea · #6 8th July 2012, 11:21 AM

Quote:

$ sudo hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 54 MB in 4.55 seconds = 11.88 MB/seconds

$ dd bs=1M count=200 if=/dev/zero of=text.data
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 107.284 s, 2.0 MB/s

That does look bad. What is it before the slowdown ?

Is this a laptop ? Does it slowdown after a sleep/wake cycle ?

george_toolan · #7 8th July 2012, 12:07 PM

What kind of sata host adapter or notebook are you using?

Can you try a different sata cable, sata port or sata host adapter (if this isn't a notebook)?

Did you check the smart values for errors?

Please check the corsair forum. There is some discussion about a new 5.02 firmware for this drive.

Try to back up all your files, install the latest firmware and reset the drive to factory defaults with a SSD secure erase.

If this doesn't work then send it back to Corsair ;-)

Flintstone · #8 9th July 2012, 10:58 AM

Quote:

Originally Posted by Flintstone

Code:

$ sudo hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads:  54 MB in  4.55 seconds =  11.88 MB/seconds

$ dd bs=1M count=200 if=/dev/zero of=text.data
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 107.284 s, 2.0 MB/s

Quote:

Originally Posted by stevea

That does look bad. What is it before the slowdown ?

Is this a laptop ? Does it slowdown after a sleep/wake cycle ?

Before the slowdown:

Code:

$ sudo hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 1078 MB in  3.00 seconds = 358.92 MB/sec

$ dd bs=1M count=200 if=/dev/zero of=text.data
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.627448 s, 334 MB/s

I will try updating the firmware and the rest of these suggestions then post back, thanks.

stevea · #9 11th July 2012, 08:32 AM

This is the one that looks bad.

Quote:

$ sudo hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 54 MB in 4.55 seconds = 11.88 MB/seconds

Writing to a file w/ dd is NOT a valid way to test your ssd speed. For example this ...

Quote:

[root@hypoxylon ~]# dd bs=1M count=200 if=/dev/zero of=/backup/foo
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.111273 s, 1.9 GB/s

nominally writes to an old disk that can't possible write above 75MB/s.

You can either dd to/from a raw SSD partition or you can use hdparm, but don't try to measure disk performance thru a file system with buffering.

----

I hate to say - but you are getting some lousy advice here. Diagnosing requires strong deductive reasoning skills and a knowledge of how things should work,

So it appears your SSD is reading on the order of 15-20 times too slow for an SSD.
Assuming your drive really is faster at th beginning (ou haven't provided the evidence, use hdparm -t.

Unless the FW was really bolluxed up when released and none of the many Corsair users noticed, then it not FW per se. Very unlikely, tho it's reasonable to update FW to remove a variable.
It is NOT caused by a bad cable, cables causes errors, not slowness.
DO chack the smart values w/ 'smartctl -a /dev/sda' but I seriously doubt this would cause a ~15x slowdown. Extremely unlikely.
No you are liely seeing some interaction between the <FW, SATA controller, driver> in increasing order of probability.

So my suggestion ....
0. verify the drive starts fast then gets slow using 'hdparm -t /dev/sda' when the system is lightly loaded.
Please report the results.
1. Look in the log (/var/log/messages and output of dmesg) looking for timeouts or disconnects or other odd messages.
2. See if the slowdown corresponds to a laptop going into suspend or some poewr event like that.
3. See if the problem remains using a different driver. This means booting a different OS or putting it on a different SATA port from a different SATA chip vendor. If an OS change doesn't help, then try a different port/chip in any case.

george_toolan · #10 11th July 2012, 09:27 AM

He already did that "Before the slowdown:"

Quote:

$ sudo hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 1078 MB in 3.00 seconds = 358.92 MB/sec

But we still don't know what kind of sata host adapter he's using.

Flintstone · #11 11th July 2012, 11:58 AM

Mobo: Asus M5A99X EVO
SATA port: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)

#12 11th July 2012, 01:07 PM

Quote:

Originally Posted by Flintstone

Mobo: Asus M5A99X EVO
SATA port: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)

I don't have any issues with the same controller

Code:

[leigh@main-pc ~]$ lspci |grep -i sata
00:11.0 SATA controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]

george_toolan · #13 11th July 2012, 01:11 PM

So have you tried one of the Jmicron ports? Even if it's only Sata II it should still be faster then 10 MiB/sec.

Or have you tried to configure your sata host adapter as ide compatibility mode instead of AHCI/RAID?

#14 11th July 2012, 01:56 PM

It may be worth getting some samples of system activity with vmstat and iostat when the system has just booted, and later when performance degrades, for comparison.

stevea · #15 12th July 2012, 04:06 AM

Gads - do any of you think deductively about problem solving ?

- EXAMINE THE LOGS (dmesg & /var/log/messages).
- TRY A DIFFERENT DRIVER
- *DO NOT* eliminate AHCI - it's required for SSD performance and should have zero impact on the issue.
- If your easiest method of trying a different driver is to switch to the Jmicron that's acceptable BUT you are changing two factors at the same time - so this is non-ideal for diagnosis.
- System level test like iostat are a completely pointless diversion. We already know there is a problem at the driver/basic I/O system, and have a decent way to test with hdparm.

It *MAY* be worth setting up hdparm to run periodically after boot and then try to characterize WHEN the slowdown occurs, but that's speculative & problematic.