SSD Write Speeds Have Slowed

I have a couple of SSDs in my system (one Intel, the other Samsung) that I’ve used for various purposes and have withstood some pretty cruel usage. Recently, Samsung has been suffering from slow write speeds during sustained loads. The dd output below reflects what I’ve experienced:

Intel (control):

root@ubuntu:~# dd if=/dev/zero of=/dev/sda bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 2.36269 s, 444 MB/s

Samsung (degraded?):

root@ubuntu:~# dd if=/dev/zero of=/dev/sdb bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 7.83307 s, 134 MB/s

But after analyzing the SMART attributes and comparing the output of hdparm, I’m beginning to think otherwise:

Intel:

root@ubuntu:~# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   29828 MB in  2.00 seconds = 14930.88 MB/sec
 Timing buffered disk reads: 1486 MB in  3.00 seconds = 495.12 MB/sec

root@ubuntu:~# smartctl -A /dev/sda
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.10.0-28-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours_and_Msec 0x0032   000   000   000    Old_age   Always       -       910068h+10m+12.820s
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       1096
181 Program_Fail_Cnt_Total  0x0032   000   000   000    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   000   000   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       1024
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       581762
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   100   100   000    Old_age   Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       581762
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       396034
249 NAND_Writes_1GiB        0x0013   100   100   000    Pre-fail  Always       -       15880

Samsung:

root@ubuntu:~# hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   31256 MB in  2.00 seconds = 15646.82 MB/sec
 Timing buffered disk reads: 1552 MB in  3.00 seconds = 517.11 MB/sec

root@ubuntu:~# smartctl -A /dev/sdb
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.10.0-28-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       6936
 12 Power_Cycle_Count       0x0032   096   096   000    Old_age   Always       -       3552
175 Program_Fail_Count_Chip 0x0032   100   100   010    Old_age   Always       -       0
176 Erase_Fail_Count_Chip   0x0032   100   100   010    Old_age   Always       -       0
177 Wear_Leveling_Count     0x0013   087   087   005    Pre-fail  Always       -       146
178 Used_Rsvd_Blk_Cnt_Chip  0x0013   100   100   010    Pre-fail  Always       -       0
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0013   100   100   010    Pre-fail  Always       -       3120
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   071   052   000    Old_age   Always       -       29
195 Hardware_ECC_Recovered  0x001a   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   253   253   000    Old_age   Always       -       0
233 Media_Wearout_Indicator 0x003a   199   199   000    Old_age   Always       -       3388132
234 Unknown_Attribute       0x0012   100   100   000    Old_age   Always       -       0
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       268
236 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       120
237 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       146
238 Unknown_Attribute       0x0012   100   100   000    Old_age   Always       -       0

Does anyone have any ideas or workarounds to potentially employ?
Thanks!

Well the Samsung shows some wear, but well within limits. No ECC/CRC errors reported. Other than trying a different cable, I can’t really suggest anything other than google search the drive model and see if there are any similar reports of it acting slow.

Also the Intel drive has been on for 103 years if I am reading that correctly!

How full are the drives? Writes can slow down as they fill up;

Empty. These are cache drives. I wipe them once in awhile to keep them nice and spry.

It’s worth a shot; I’ll swap out the cable when I get home.

And you are correct. I didn’t even notice how large that value was…

Test the drive latency perhaps. That can be more indicative of a bad SSD than transfer speed.

Well unless you are a time traveler, I would take those “Smart” parameters with a grain of salt. They are somewhat unreliable.

Do you have a windows PC lying around? You could try install the Samsung Magician to test the drive and update it’s firmware. You could also over-provision the drive a bit more, which may help if it is getting flogged.

~60% difference

root@ubuntu:~# ioping -c10 /dev/sda
4 KiB from /dev/sda (block device 111.8 GiB): request=1 time=1.34 ms
4 KiB from /dev/sda (block device 111.8 GiB): request=2 time=1.28 ms
4 KiB from /dev/sda (block device 111.8 GiB): request=3 time=1.31 ms
4 KiB from /dev/sda (block device 111.8 GiB): request=4 time=1.32 ms
4 KiB from /dev/sda (block device 111.8 GiB): request=5 time=1.28 ms
4 KiB from /dev/sda (block device 111.8 GiB): request=6 time=1.27 ms
4 KiB from /dev/sda (block device 111.8 GiB): request=7 time=620 us
4 KiB from /dev/sda (block device 111.8 GiB): request=8 time=1.31 ms
4 KiB from /dev/sda (block device 111.8 GiB): request=9 time=1.28 ms
4 KiB from /dev/sda (block device 111.8 GiB): request=10 time=604 us

--- /dev/sda (block device 111.8 GiB) ioping statistics ---
10 requests completed in 9.01 s, 860 iops, 3.36 MiB/s
min/avg/max/mdev = 604 us / 1.16 ms / 1.34 ms / 275 us
root@ubuntu:~# ioping -c10 /dev/sdb
4 KiB from /dev/sdb (block device 119.2 GiB): request=1 time=1.84 ms
4 KiB from /dev/sdb (block device 119.2 GiB): request=2 time=1.73 ms
4 KiB from /dev/sdb (block device 119.2 GiB): request=3 time=1.93 ms
4 KiB from /dev/sdb (block device 119.2 GiB): request=4 time=1.87 ms
4 KiB from /dev/sdb (block device 119.2 GiB): request=5 time=1.83 ms
4 KiB from /dev/sdb (block device 119.2 GiB): request=6 time=1.88 ms
4 KiB from /dev/sdb (block device 119.2 GiB): request=7 time=1.90 ms
4 KiB from /dev/sdb (block device 119.2 GiB): request=8 time=1.94 ms
4 KiB from /dev/sdb (block device 119.2 GiB): request=9 time=1.78 ms
4 KiB from /dev/sdb (block device 119.2 GiB): request=10 time=1.81 ms

--- /dev/sdb (block device 119.2 GiB) ioping statistics ---
10 requests completed in 9.02 s, 539 iops, 2.11 MiB/s
min/avg/max/mdev = 1.73 ms / 1.85 ms / 1.94 ms / 63 us

I do. I can work on that and swapping the cable over the weekend if we still think it’s worthwhile. I’ve accrued a nice backlog of tasks at school/work for the rest of this week, so I’d rather not start messing with hardware until I have some more time.