Crappy SSD Performance

schmidtbag · 2013-08-28 03:28:04

I have a 64GB Adata SP900 on a SATA III port. The drive works pretty good, but the performance is considerably worse than what it should be. I get write speeds between 80-130MB/s and read speeds under 300MB/s. Doesn't seem to matter what the file size is. I should be getting well over 300MB/s for both read and write. What's really annoying is I get better performance out of a RAID 0 setup with 2 hard drives (at least when it comes to file copies).

I tried changing the I/O scheduler and I've always had "discard" on in fstab.

WonderWoofy · 2013-08-28 03:44:46

This is not very much info to go off of. Filesystem, alignment, sequential, random? What is going on here? You haven't really said much of anything.

fukawi2 · 2013-08-28 04:35:56

schmidtbag wrote:

I should be getting well over 300MB/s for both read and write.

What is your basis for those expectations?

Thorsten Reinbold · 2013-08-28 04:55:13

schmidtbag wrote:

I have a 64GB Adata SP900 on a SATA III port. The drive works pretty good, but the performance is considerably worse than what it should be. I get write speeds between 80-130MB/s and read speeds under 300MB/s. Doesn't seem to matter what the file size is. I should be getting well over 300MB/s for both read and write. What's really annoying is I get better performance out of a RAID 0 setup with 2 hard drives (at least when it comes to file copies).
I tried changing the I/O scheduler and I've always had "discard" on in fstab.

I think those are normal stats for that SSD. See this benchmark.

Edit: ...or maybe not? Sorry, I only had a quick look at the first tests.

Last edited by Thorsten Reinbold (2013-08-28 04:59:10)

schmidtbag · 2013-08-28 13:13:05

Right now I care most about sequential reading speeds. I'm using ext4. The advertised speed of the SSD is around 550MB/s read speed, though realistically it tends to be around 400MB/s. I'm aware that I'm not always going to get an incredibly fast speed, but copying large 200MB files should not be taking longer than my RAID HDD setup.

I'd like to point out that I do have AHCI enabled.

Doing some research, I wasn't aware alignment mattered so much. I'm not really sure if the drive is properly aligned or not but it's probably safe to assume that it isn't. However, would that really knock off as much as 100MB/s?

Last edited by schmidtbag (2013-08-28 13:14:05)

Arctus · 2013-08-28 21:54:18

Possibly: http://www.wwpi.com/index.php?option=co … id=2701018

You can use parted to check whether it's aligned or not. It's pretty straightforward.

fukawi2 · 2013-08-28 23:11:00

schmidtbag wrote:

However, would that really knock off as much as 100MB/s?

If it's not aligned properly, each read of "1 block" actually requires 2 blocks to be read... So you're doubling the IOPS required, so yes I would not be surprised at such a performance impact.

schmidtbag · 2013-08-29 01:06:07

So I tried using gparted where I pushed back by 3MB (for some reason it wouldn't let me do 2MB - the option to disable "round by cylinder" didn't exist) and then got it back to 2MB. It seemed to make read speeds a little faster but no impact on write speeds. Should I push it back to 1MB?

fukawi2 · 2013-08-29 01:13:48

AFAIK, gparted automatically aligns correctly... You can check by right-clicking the partition, then selecting "Information". At the bottom of that window will tell you the First Sector, which should be a multiple of 512, usually 2048 or 4096 IIRC.

WonderWoofy · 2013-08-29 02:13:39

The default in gdisk, fdisk, and parted these days is 2048. But it will also allow you to specify if you please.

Pse · 2013-08-29 20:06:51

Slow SATA controller? RAID drives would not be affected as they are using two SATA channels? Have you looked at IO benchmarks of your chipset?

Last edited by Pse (2013-08-29 20:07:14)

schmidtbag · 2013-08-29 20:48:06

Pse wrote:

Slow SATA controller? RAID drives would not be affected as they are using two SATA channels? Have you looked at IO benchmarks of your chipset?

I don't remember my specific SSD tested with my particular controller (it's an AMD chipset - I think something in the 800SB series) but I've seen other tests with my controller, where with single drives it's slightly slower than it's intel counterpart. While this drive is advertised to go as fast as 550MB/s read speed, my particular controller might reduce that number to 525MB/s. It's faster than the intel counterpart in RAID, but that's irrelevant since I'm not doing RAID with this SSD.

Anyways, the controller supports 6 SATA III ports, so even if I were to knock off a whole Gb/s of SATA III's total bandwidth, it should still be able to write faster than it does now.

cfr · 2013-08-29 21:42:08

Are you sure all the partitions are now properly aligned?

schmidtbag · 2013-08-30 02:35:48

So I went to double check - it still says there's only 2MB spare at the beginning of the drive, but it says the fist sector is at 4096, which doesn't really make sense. Either way, shouldn't that still be ok in terms of alignment?

I'm using KDE with nepomuk off if anyone thinks that makes a difference.

Last edited by schmidtbag (2013-08-30 02:47:59)

cfr · 2013-08-30 02:50:52

If you only have one partition, yes.

The sectors are 512 bytes, right? So isn't that right i.e. 2M will be at 4096?

On mine, my first partition starts at 2048 and I have 1,0007 KiB free.

WonderWoofy · 2013-08-30 03:06:57

If you are using gdisk, it should try to influence you as much as it can into properly aligning partitions. That is, if you accept the default start points I am pretty sure they will be aligned. But also, if you stick do making your partitions with Megabytes or Gigabytes (or presumably terabytes, etc.) it should come out fine. Just stay away from using Kilobytes and Bytes (or just the number of raw sectors).

cfr · 2013-08-30 03:13:55

That's true if you are creating partitions but I thought this was about an existing partition scheme which was not (?) correctly aligned. I'm confused...

WonderWoofy · 2013-08-30 03:17:57

I don't think there was any real specificity in terms of what steps were taken to create the setup. There was just the discussion of why the SSD was not performing as expected, and a comparison to an existing RAID0 I think.

But that is a good point. If using existing partitions, it is a very good idea to make sure that the partitions are aligned… or just use btrfs across the whole disk and don't even worry about partitions or alignment

schmidtbag · 2013-08-30 03:44:55

So, if my drive appears to be correctly aligned, any other suggestions? Also I'm just wondering - is btrfs designed to detect SSDs and align properly? Because I don't fully understand why otherwise it wouldn't be affected the same way. I might consider switching to it, if it'll actually make enough of a difference - I have heard btrfs is slower.

On the other hand, I might just clone my setup to a separate drive, wipe the SSD, and run some other tests in it. See how it performs in Windows, how it performs with btrfs, and see if re-formatting it with ext4 will help. I'd obviously rather avoid doing all of that though, but it would help prove if there's a hardware fault.

The thing is I'm not getting data loss and the drive is overall a good performer, but it's still operating at half it's total speed.

EDIT:
I would like to point out that the setup I have on the SSD was originally on a mechanical hard drive that I cloned to the SSD. I enabled discard in fstab but I'm not sure if there was some other step I was supposed to take, other than the alignment.

Last edited by schmidtbag (2013-08-30 03:46:55)

WonderWoofy · 2013-08-30 03:53:27

If you cloned it, I assume that you mean you dd'ed it. If that is the case, then maybe you are seeing defragmentation. You should rsync it over with the btrfs filesystem mounted with the autodefrag mount option. Btrfs does autodetect ssd's and shoudl align properly.

But it rather sounds like you have a fascination with trying to benchmark as fast as possible. So maybe moving to ext4 would be the way to go. Btrfs is pretty well performing these days, but it still is a bit behind ext4.

mich41 · 2013-08-30 07:56:22

If "cloned" means dd, the flash controller has no way to know that blocks unallocated to files that have been dd'd onto it are in fact garbage and it keeps them. So your drive thinks is full and behaves like such.

If this is the case, you will need to find some utility to scan the filesystem and discard unnecessary blocks (IDK if such utility exists ) or reformat and copy only the files (cp -a).

schmidtbag · 2013-08-30 13:08:11

I used clonezilla, which is based on dd. So, assuming that even after re-aligning that my scenario is known to cause performance drops, then I can work with that. Isn't there something that can zero-out empty space to fix such an issue?

And I'm not trying to get the fastest speed possible, I just think getting less than half the total speed is a problem. That's like buying an 8 core CPU and only being allowed to use 4, with 2 of those being hyper-threaded (as HT is slower than a physical core). I already know that my maximum speed is capped by the controller, but it should not be 300MB/s slower.

Last edited by schmidtbag (2013-08-30 13:08:49)

alphaniner · 2013-08-30 13:30:14

Have you tried a benchmarking tool that uses raw I/O to the disk? It's not SSDs, but in my experience with enterprise RAIDs I never see the same speeds when working with actual filesystem data that I see when working with raw benchmarking tools.

WonderWoofy · 2013-08-30 17:29:24

schmidtbag wrote:

I used clonezilla, which is based on dd. So, assuming that even after re-aligning that my scenario is known to cause performance drops, then I can work with that. Isn't there something that can zero-out empty space to fix such an issue?

Probably, but I have never tried to use anything like that. The best way to ensure that your files are written sequentially, in an efficient manner, it to copy the files over from one disk to another. You can use cp -a but I have heard that this does not copy over all of the extended attributes. So it is recommended you use something like rsync -aAXv or tar to do this, as those tools will copy over the fiels exactly as is.

The above mentioned method also has the advantage of not copying the empty space, so it typically is much much faster than using dd (or clonezilla or whatever) unless you are copying over a nearly full disk/partition. But if you have a near full disk/partition you probably shouldn't be using btrfs anyway, as it has some issues with this scenario still.

Just remember to mount the SSD with the 'autodefrag' mount option before copying over your data. THen use the autodefrag mount option in general from that point forward. I guess you would do manual defragmentation, but usage of the online defrag tool is not quite as straight forward as it should be (yet?).

schmidtbag · 2013-08-30 21:27:21

So I tried btrfs and didn't seem to get any difference - writing speeds were more consistent, but still below 120MB/s.

However, after re-formatting the drive I have managed to get read speeds beyond 450MB/s, which is definitely acceptable - 550MB/s is more a theoretical maximum than a typical maximum, and considering my controller isn't the fastest around, 450MB/s is definitely a good enough read speed. I'd still like to see what I can do to improve write speed though, as that is still pretty bad for a SATAIII SSD.

Arch Linux

#1 2013-08-28 03:28:04

Crappy SSD Performance

#2 2013-08-28 03:44:46

Re: Crappy SSD Performance

#3 2013-08-28 04:35:56

Re: Crappy SSD Performance

#4 2013-08-28 04:55:13

Re: Crappy SSD Performance

#5 2013-08-28 13:13:05

Re: Crappy SSD Performance

#6 2013-08-28 21:54:18

Re: Crappy SSD Performance

#7 2013-08-28 23:11:00

Re: Crappy SSD Performance

#8 2013-08-29 01:06:07

Re: Crappy SSD Performance

#9 2013-08-29 01:13:48

Re: Crappy SSD Performance

#10 2013-08-29 02:13:39

Re: Crappy SSD Performance

#11 2013-08-29 20:06:51

Re: Crappy SSD Performance

#12 2013-08-29 20:48:06

Re: Crappy SSD Performance

#13 2013-08-29 21:42:08

Re: Crappy SSD Performance

#14 2013-08-30 02:35:48

Re: Crappy SSD Performance

#15 2013-08-30 02:50:52

Re: Crappy SSD Performance

#16 2013-08-30 03:06:57

Re: Crappy SSD Performance

#17 2013-08-30 03:13:55

Re: Crappy SSD Performance

#18 2013-08-30 03:17:57

Re: Crappy SSD Performance

#19 2013-08-30 03:44:55

Re: Crappy SSD Performance

#20 2013-08-30 03:53:27

Re: Crappy SSD Performance

#21 2013-08-30 07:56:22

Re: Crappy SSD Performance

#22 2013-08-30 13:08:11

Re: Crappy SSD Performance

#23 2013-08-30 13:30:14

Re: Crappy SSD Performance

#24 2013-08-30 17:29:24

Re: Crappy SSD Performance

#25 2013-08-30 21:27:21

Re: Crappy SSD Performance

Board footer