PDA

View Full Version : SSD starts fast then slows down on F16



Flintstone
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?


$ 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

pjfg
7th July 2012, 04:50 PM
Do you have the latest firmware?

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

marko
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

Yellowman
7th July 2012, 05:40 PM
I would use wiper.sh (to trim) after editing fstab

change the / fstab line to


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



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

pjfg
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
8th July 2012, 11:21 AM
$ 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
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
9th July 2012, 10:58 AM
$ 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 ?

Before the slowdown:

$ 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
11th July 2012, 08:32 AM
This is the one that looks bad.


$ 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 ...

[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
11th July 2012, 09:27 AM
He already did that "Before the slowdown:"


$ 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
11th July 2012, 11:58 AM
Mobo: Asus M5A99X EVO
SATA port: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)

Yellowman
11th July 2012, 01:07 PM
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


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

george_toolan
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?

pjfg
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
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.

pjfg
12th July 2012, 10:26 AM
Gads - do any of you think deductively about problem solving ?

- EXAMINE THE LOGS (dmesg & /var/log/messages).


That's a given, don't you think?



- 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.


Perhaps you're not thinking deductively? hdparm is great and all, but it gives zero information on how the rest of the system is performing.

It would be interesting to see how the system changes behaviourally between first boot and when the degradation becomes apparent. Perhaps that would give some clue as to the cause of the issue.

Actually, running hdparm with the --direct switch would be helpful as we would have a measure of raw performance thereby eliminating controller/firmware issues.

Flintstone
12th July 2012, 01:00 PM
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.

dmesg & /var/log/messages do not contain any errors. I will try to reproduce the problem by booting into Windows, it is the obvious next step. Just need to wait until after the next Firefox release as I am working on a feature that I need to get finished.

Flintstone
14th August 2012, 03:18 PM
Not finding anything wrong with my SSD I decided to check my NVIDIA GEForce GTX 560 Ti graphics card. The card itself appears to work fine except for causing the major slowdown. If I go back to the nouveau driver my PC becomes ridiculously slow. Uninstalling all NVIDIA drivers and reinstalling them has helped a little as I can run for a few days now without the slowdown.

Seems like Zotac (the card vendor) do not provide firmware updates whilst other vendors like Gigabit do provide updates for their versions of this card. The firmware that I have doesn't allow a high enough voltage. I suspect that if Zotac ever release firmware for this card they will up the voltage and it may fix this issue with slowness.