Extremely Slow Samsung 850 EVO SSD

Broccoli

n00b
Joined
Nov 28, 2015
Messages
16
Hello. First posting. I have a computer that we recently upgraded the hard drive to a Samsung 850 EVO 500gb SSD. I upgraded 3 weeks ago, did some benchmarks and found the SSD is extremely slow for writes, especially small writes. Slow, as a 20 year old hard drive. I have never seen benchmarks this slow for SSD.

Here is what I did:
Partitioned SSD. Partitions are 1meg aligned, with 10% over-provision.
Cloned old hard drive to new SSD.
Configured BIOS and Windows to use AHCI.
Updated Intel storage drivers to newest, ver 11.6.0.1030.
Verified TRIM is enabled.
Set windows SSD optimizations, disable defrag, restore points, indexing, etc.

I finally found a setting that improved the performance. The windows write caching was turned off. Turning it on gives better performance. But, I feel that the only valid way to benchmark a drive is with caching turned off. And without write-caching, there is some serious performance problem with this SSD.

Here are the system specs:
Asus P8H61-M, i5-2400, 8gb DDR3, Windows 7 Pro 64bit SP1, Samsung EVO 850 500gb.

I realize the motherboard only has SATA2 3gb ports, and limits max drive performance to ~300mb/sec. But right now I am most concerned with the writes and small writes. Maybe Santa will bring me something with SATA3 ports.

Thanks for any feedback or ideas.

adlo3l.png

35idshu.png

14nfi9g.png
 
Did you try benchmarking the drive before you went all tryhard on the settings and configuration? Also is that weird the drive shows as a SCSI in the title of AS SSD?
 
I have only ever once cloned a HDD and it didn't work out too well. Mind you this was quite a few years ago now, but the donor-drive was quite a bit smaller than the drive I was cloning to. Well ended up that after I cloned TO the drive, which had already been formatted mind you, that drive's storage size went down to that of the donor's capacity. In short it seemed like cloning it quite literally cloned it... I had to format it to get it to function at full capacity again.

In short, what I'm wondering is if perhaps your sector size was screwed up and it is now configured to some un-optimized setting?

Also, I am pretty sure Samsung has a rather stout SSD utility suite for the drives, perhaps it will provide some info?
 
Did you try benchmarking the drive before you went all tryhard on the settings and configuration? Also is that weird the drive shows as a SCSI in the title of AS SSD?

I did try benchmarking after I finished cloning the drive and got windows running on the SSD. I used the benchmark utility that comes with the Samsung magician software. It was a bit slow. That's when I started to read up on SSD optimizing, enabling AHCI, etc. The Samsung benchmark tool is simple and only reports a (sequential ?) read/write number. Sometime later I tried the benches I posted above and found how slow it is.

I don't know why it shows as a SCSI drive. Maybe this is what the intel drivers are telling AS-SSD? I'm pretty sure I installed the right intel drivers.
 
Last edited:
Wow that's slow. Not sure if it's feasible, but can you try reformatting it to see if the speeds come back up?
 
I have only ever once cloned a HDD and it didn't work out too well. Mind you this was quite a few years ago now, but the donor-drive was quite a bit smaller than the drive I was cloning to. Well ended up that after I cloned TO the drive, which had already been formatted mind you, that drive's storage size went down to that of the donor's capacity. In short it seemed like cloning it quite literally cloned it... I had to format it to get it to function at full capacity again.

In short, what I'm wondering is if perhaps your sector size was screwed up and it is now configured to some un-optimized setting?

Also, I am pretty sure Samsung has a rather stout SSD utility suite for the drives, perhaps it will provide some info?

I have cloned hard drives in the past and never had a problem with it, so I didn't expect a problem cloning a HDD to SDD. People do this all the time, don't they? It should be a common practice to clone HDD to SDD for upgrades.

The Samsung software does come with migration/cloning utility. I found it didn't run on the original hard drive, can't remember the reason. I ended up using Macrium Reflect to do the clone. The source HDD was 500gb and the SSD is 500gb. There is plenty of free space, so everything fits comfortably. The idea is to make new partitions on the new drive first, then clone over the data. Maybe this should be called a filesystem clone?

I was thinking about sector sizes, but I don't know how to check that. What should be checked?
 
Wow that's slow. Not sure if it's feasible, but can you try reformatting it to see if the speeds come back up?

I am really trying to avoid this option. Having to shuffle the data off to a backup drive and then back on to the SSD... a lot of work. Wouldn't that be what I did to begin with, essentially. There might be the risk that whatever is wrong with this setup just persists after a backup/restore?
 
Right, but it will help to isolate if the issue is volume/partition related or if it's drive related.
 
Right, but it will help to isolate if the issue is volume/partition related or if it's drive related.

OK. What would be the best way to do a backup/restore that would not preserve the volume/partition and isolate the problem? Assuming the problem here is the partition. Or should I just do a clean install of windows for testing?
 
OK. What would be the best way to do a backup/restore that would not preserve the volume/partition and isolate the problem? Assuming the problem here is the partition. Or should I just do a clean install of windows for testing?

A clean install for testing would be best. If the problem persists try a linux distro (for giggles). If the problem persists in a fresh windows and in a linux then I'd wager the drive is defective in some way.
 
A clean install for testing would be best.

I would also do a clean install and NOT screw around with trying to be overly clever with aligning the drive or running utilities. Format the drive from Windows Setup. Just install the OS and drivers, then benchmark and see what it does.
 
Alright. I can try some different SATA cables. Easy enough. I might look into sector sizes/alignments. It might be a some days before I can try a reinstall.

I have question on a reinstall. I've read people recommend doing a "secure erase" on the SSD before reinstall. Should I try that? I guess secure erase resets all the SSD memory cells.
 
Alright. I can try some different SATA cables. Easy enough. I might look into sector sizes/alignments. It might be a some days before I can try a reinstall.

I have question on a reinstall. I've read people recommend doing a "secure erase" on the SSD before reinstall. Should I try that? I guess secure erase resets all the SSD memory cells.

dont need to
 
Why don't you leave the old hdd in and boot to it with the ssd as a secondary drive. Re run you benchmarks to see what you get.
 
OK. What would be the best way to do a backup/restore that would not preserve the volume/partition and isolate the problem? Assuming the problem here is the partition. Or should I just do a clean install of windows for testing?

Have you considered using Windows' own backup solution? You'd be able to backup everything, format the drive again, boot from the old HDD and run some tests.
If things are as they should... install Windows (not a clone), run tests again just to be sure.
If things are still good, can run restore the Windows backup.

A few things have came back to me on my past outings and issues with all this AHCI stuff. My new theory is perhaps there's something registry related. I don't know if Intel has anything similar, but I know that with AMD there was an entry or two deep in the CurrentControlSet area that pertained to performance. (Sorry, it's been a few years <_>) If that's the case in any similar way then an install may switch the right flags :p

In any event I think it's universally agreed upon that a fresh install is the right choice. heh
 
I have tried a few more tests based on everyone's replies. Here are the results:

Tried 3 different SATA cables. No change.
Disconnected optical drive. No change.
Tried different SATA ports on the motherboard. No change.
Tried booting windows into safe mode. No change.
Changed BIOS back to IDE mode. No change.
Moved SSD to a different computer, set as a secondary drive. No change.

I tried trick0502's idea of booting off the original HDD with the SDD as a secondary drive. Windows would not allow this. Disk Management showed the SSD as "offline" without a drive letter. The error message said there was a "signature collision" with an existing drive. I don't know what this is about. Maybe the two drives (the old HDD and new SSD) have the same serial number because they were cloned? Windows thinks they are the same drive?

I investigated sector sizes and alignments. The Samsung 850 shows as a 512 byte physical sector size. From what I can read this how SSDs behave. My partitions are definitely aligned to 1 meg boundaries. There shouldn't be any problem with sectors or alignments.

I've run out of ideas. Looks like the only test left is to re-install a clean windows (or Linux :). Any other ideas? It might be several more days or a week or two before I can do a re-install.
 
Broccoli said:
Asus P8H61-M

I see you tried running the SSD on a different computer, so this probably isn't it, but the original version of this motherboard was one of those that were affected by the Intel Cougar Point SATA bug. Do you have the B2 or B3 version of this motherboard? CPU-Z is probably the easiest way to check the revision number.
 
I see you tried running the SSD on a different computer, so this probably isn't it, but the original version of this motherboard was one of those that were affected by the Intel Cougar Point SATA bug. Do you have the B2 or B3 version of this motherboard? CPU-Z is probably the easiest way to check the revision number.

yea wasn't that had to do with SATA disappear and not performance? Or was that a different error?
 
I've run out of ideas. Looks like the only test left is to re-install a clean windows (or Linux :). Any other ideas? It might be several more days or a week or two before I can do a re-install.

Wipe the drive completely. As in, complete wipe. Format it as a regular drive, and leave the sector sizes alone (leave it default). Leave the drive blank. Connect it to the computer as a secondary drive or whatever, and run a few benchmarks on it. If it does the same thing, try it on a different computer. If it still does the same thing, time to exchange it.
 
Your benchmarks are all done without write cache ?

do you have the options to benchmark er similar drive and see if is indeed just from the missing cache or its actually the drive.

because most benchmark measure read/writes while bypassing the cache entirely. ( unless you have rapid mode which ignores the bypass request and thereby fake benchmark numbers)

IF you benchmark was indeed writing/reading solely from cache while you have cache enabled you would see a lot bigger nummbers.

I think when you disabled windows write cache you also disabled anykind of buffer to groups writes together. i mgiht be wrong but i belevie windows writes in small lumps and since you have to rewrite an entire page on the SSD you small tinysingle writes at a time nees alot fo readign adn rewrite a page.
where as wit windows cache enabled you congest those write into one operation and can fill out an entire page and therby go with maximum speed. even though its not directly due to the cache lazy write feature ( delaying the actually writes)

the same issues you have with raid5 writse drops to the floor without windows caching cause tiny small writes forces you to read data so you can write a entire stripe at a time. have to recaculate the parity)


i understand you want to measur the drives performance and not the cache (lazy writes) speed but i think that lazy writes are responsibel for the diffrent you are experiencing but just lack of write congestion. whicvh i belive would be totaly fair kills your drive performance
 
ok, i have 2 questions:

1) was it a new drive? i'm guessing you bought it used.

2) why are people discouraging secure erase? i'm pretty certain that will solve your problem, because it did it for me. simply formatting the drive will not help.

i was in the same boat as you. my corsair P64 felt sluggish after many years of continuous use (installing threshold 2 took around 45 minutes...), so i ran benchmarks. this was the result:

vEPWfG7.jpg


yes i know, it's an old drive, and i'm on SATA2, but still, this drive is advertised at a seq 180 MB/s write.

this benchmark was run after a clean install of win10 with a format beforehand.

try a secure erase, it will take only 30 minutes (ok, the secure erase itself will only take a few seconds, but imaging your system and restoring it will take time).

after this, my P64 is now back to advertised speeds.

there are tons of guides on how to do it with parted magic, so i'd recommend just doing that.
 
I see you tried running the SSD on a different computer, so this probably isn't it, but the original version of this motherboard was one of those that were affected by the Intel Cougar Point SATA bug. Do you have the B2 or B3 version of this motherboard? CPU-Z is probably the easiest way to check the revision number.

Good memory, I remember reading about that bug with the B2 rev chipset when I bought these components. By time I bought this motherboard they had fixed it, and indeed I do have a motherboard with rev B3 chipset. (double checked with CPU-Z)
 
Your benchmarks are all done without write cache ?

do you have the options to benchmark er similar drive and see if is indeed just from the missing cache or its actually the drive.

because most benchmark measure read/writes while bypassing the cache entirely. ( unless you have rapid mode which ignores the bypass request and thereby fake benchmark numbers)

IF you benchmark was indeed writing/reading solely from cache while you have cache enabled you would see a lot bigger nummbers.

I think when you disabled windows write cache you also disabled anykind of buffer to groups writes together. i mgiht be wrong but i belevie windows writes in small lumps and since you have to rewrite an entire page on the SSD you small tinysingle writes at a time nees alot fo readign adn rewrite a page.
where as wit windows cache enabled you congest those write into one operation and can fill out an entire page and therby go with maximum speed. even though its not directly due to the cache lazy write feature ( delaying the actually writes)

the same issues you have with raid5 writse drops to the floor without windows caching cause tiny small writes forces you to read data so you can write a entire stripe at a time. have to recaculate the parity)


i understand you want to measur the drives performance and not the cache (lazy writes) speed but i think that lazy writes are responsibel for the diffrent you are experiencing but just lack of write congestion. whicvh i belive would be totaly fair kills your drive performance



Yes, In my first post the Samsung 850 EVO benchmarks were with windows write cache disabled. That's what got me into this and how I found write cache was disabled. I did do a set of benchmarks with windows write cache enabled. When enabled, the write speed is almost the same as read speed. But what is the real performance of the SSD? Shouldn't performance be measured without write caching? Otherwise any crazy benchmark numbers become possible.

I do understand what you are saying: how the write cache could be batching a large number of small writes into a bigger write. I think the 4k random write would be important because this is window's default cluster size.

I really have a hard time believing that the real write performance of the 850 EVO is only kilobytes/sec and access times of 13 milliseconds. Even if, in the case of a small random write, the SSD has to do a read,modify,erase,write, does that really take 13 milliseconds? This is nanometer silicon. It should be fast. Samsung specs say 4KB 1QD writes are 40,000 IOPS. I am getting 80 IOPS. I couldn't find anything in Samsung specs about OS drive cache.

I am trying to figure out if there is something wrong with my configuration, or if the drive is defective. The numbers I have are so slow, I think there is something wrong.

I don't have access to any other Samsung ssd drives. But I did do a benchmark today on a different brand. I'll follow up on another post with some benches.

Here are a set of benchs of my 850 EVO. One set with windows cache enabled, one set with windows cache disabled.

2hn5amr.png

29cqdr9.png
 
ok, i have 2 questions:

1) was it a new drive? i'm guessing you bought it used.

2) why are people discouraging secure erase? i'm pretty certain that will solve your problem, because it did it for me. simply formatting the drive will not help.

i was in the same boat as you. my corsair P64 felt sluggish after many years of continuous use (installing threshold 2 took around 45 minutes...), so i ran benchmarks. this was the result:

1) It is a new drive. Just purchased last month as a new item from a big, reputable computer store. The drive was sealed in retail packaging, bought in person.

This big, new drive is performing like your small, years-old drive :(

In benchmark picture you posted, was that with windows write cache enabled?


2) If and when I get a chance to reformat/reinstall I will try the secure erase. But I wonder, what does secure erase do that TRIM does not do?
 
At work today I had to rebuild an old pc with a new SSD. The SSD was brand new, a SPCC 120gb model. Computer was older, Pentium E6600, 4gb ram. New install of windows 7 pro sp1, with full updates. I wanted to do two sets of benchmarks, same tests as with the 850EVO. 1 set with windows write cache on, and one set off.

ATTO shows little change depending on write cache setting, but slightly lower performance for small writes when cache is off.

CDM shows much lower write performance with write cache off. 4k is not as bad as 850EVO.

29d8pid.png

5xncip.png
 
I think you are putting way too much thought and effort into this. I do have to hand it to you that you found what the issue was (write caching turned off), but that's pretty much where your problem stopped. Below are screenshots of my drives.

vncgif.jpg


The speeds can vary WILDLY depending on how many runs you do, how your system is configured, etc. I can tell you that I use my rig for everything: gaming, music production (DAW), general productivity, and it has zero problems with anything I throw at it.

Your last set of benches with write caching turned on look spot on. Leave it alone, and leave that setting turned on.

I honestly think you're done here. The drive seems to be performing properly now.
 
1) It is a new drive. Just purchased last month as a new item from a big, reputable computer store. The drive was sealed in retail packaging, bought in person.

This big, new drive is performing like your small, years-old drive :(

In benchmark picture you posted, was that with windows write cache enabled?


2) If and when I get a chance to reformat/reinstall I will try the secure erase. But I wonder, what does secure erase do that TRIM does not do?

Strange that a new drive behaves like this.

Anyway, secure erase sends a voltage spike to the nand cells to completely reset them on a hardware level, instead of just overwriting through software. Software cannot access all the cells on the drive.
 
I think you are putting way too much thought and effort into this. I do have to hand it to you that you found what the issue was (write caching turned off), but that's pretty much where your problem stopped. Below are screenshots of my drives.


The speeds can vary WILDLY depending on how many runs you do, how your system is configured, etc. I can tell you that I use my rig for everything: gaming, music production (DAW), general productivity, and it has zero problems with anything I throw at it.

Your last set of benches with write caching turned on look spot on. Leave it alone, and leave that setting turned on.

I honestly think you're done here. The drive seems to be performing properly now.


Thanks for posting the benchmarks. It is good to have more datapoints. Were those benchmarks with Windows' write caching enabled? This is what I am trying to figure out. Could you redo a benchmark with a Samsung 850, and Windows' write caching turned off?

I posted a set of benches showing a cheap Silicon Power SSD has minimal performance drop when write cache is turned off. But the Samsung 850 shows a great performance drop. So, why this behavior? It seems to me that the 850 has serious problems with small writes.
 
Thanks for posting the benchmarks. It is good to have more datapoints. Were those benchmarks with Windows' write caching enabled? This is what I am trying to figure out. Could you redo a benchmark with a Samsung 850, and Windows' write caching turned off?

I posted a set of benches showing a cheap Silicon Power SSD has minimal performance drop when write cache is turned off. But the Samsung 850 shows a great performance drop. So, why this behavior? It seems to me that the 850 has serious problems with small writes.

Those benchmarks were all with write caching enabled. I'm not going to turn write caching off and run them all again; it's too much of a waste of time.

Again, if you are not seeing any serious slow down, it's kinda pointless to be running and comparing synthetic benchmarks in a less than optimal scenario (write caching off). Just leave that option on. Your benchmarks with it on are about par for the course, which means you are basically all set.
 
Those benchmarks were all with write caching enabled. I'm not going to turn write caching off and run them all again; it's too much of a waste of time.

Again, if you are not seeing any serious slow down, it's kinda pointless to be running and comparing synthetic benchmarks in a less than optimal scenario (write caching off). Just leave that option on. Your benchmarks with it on are about par for the course, which means you are basically all set.

Cliff notes:
Stop touching stuff
 
Cliff notes:
Stop touching stuff

lol

Well, to be fair, he caught it after the fact, so no harm there. I understand he's concerned, but I just proved (and he did himself, actually), that everything looks good once caching is turned on.

If he still has issues, I'd recommend he runs some actual file transfers and time them. Now if the 850 is drastically SLOWER than that el cheapo drive, maybe he does have a problem where the drive needs to be replaced. That being said, his benches don't show that, so I don't think that's going to be the case at all.
 
I am concerned about this as well and have proved (to myself) that
a Sandisk Extreme-One (so, "sandisk extreme") cares little for windows-cache, it performs as well either way (on or off).
Not sure if I could upload a picture (OK, no) .

Nevermind, you all seem hell bent on pushing windows-cache, and I disagree.
Drives should be benchmarked with no cache, and then used at the user's discretion.
Crystal diskmark 5.1.0
4k (so single queue)
read 21.85, write 80.35, no cache.
The extreme pro performed way poorer than that with no cache, but WITH cache, performed around the same.
Switching my drives around lost all my local pictures, but they're online in my blog somewhere and available upon request.
Now I have the onerous task of choosing a new larger SSD that performs at least as well as the Sandisk-extreme.
Using Caching results doesn't help.
 
If a disk benchmark really wants to test the underlying hardware (as opposed to how much RAM the OS will use as a disk cache) it needs to tell the OS to flush all writes out to hardware as part of the benchmark.

On linux this would involve fsync() or similar. Not sure about windows.
 
Back
Top