Slashdot Mirror
Samsung's SSD 840 Read Performance Degradation Explained
An anonymous reader writes with a link to TechSpot's explanation of the reason behind the performance degradation noticed by many purchasers of certain models of Samsung SSD (the 840 and 840 EVO), and an evaluation of the firmware updates that the firm has released to address is. From the piece, a mixed but positive opinion of the second and latest of these firmware releases: "It’s not an elegant fix, and it’s also a fix that will degrade the lifetime of the NAND since the total numbers of writes it’s meant to withstand is limited. But as we have witnessed in Tech Report’s extensive durability test there is a ton of headroom in how NAND is rated, so in my opinion this is not a problem. Heck, the Samsung 840 even outlasted two MLC drives.
As of writing, the new firmware has only been released for the 2.5” model of the SSD 840 EVO, so users of the 840 EVO mSATA model still have to be patient. It should also be noted that the new firmware does not seem to work well with the TRIM implementation in Linux, as this user shared how file system corruption occurs if discard is enabled."
Clearly the problem is there also on the 840!
This reminds me of all of the abuse spewed by Samsung owners who were either completely ignorant or refused to acknowledge a problem.
Although that's because my 840 EVO is still in the box waiting to be installed...
I tried hdtune on my older sata 2 samsung 470, and it's hdtune graph looks worse, with a minimum of 40MB/s. The drive's still in my system, but I don't use it anymore.
There is a reason why I bought the 840 PRO and it's MLC. MLC is a bit more proven and reliable.
So, what they're going to do to keep the performance up to the advertised value, is to rewrite all the data at least once per 2 months. That's actually a good chunk of the rated TB written for SSDs, whose low values in that regard are only acceptable if you take into account that most data isn't continuously rewritten. If I had one of those SSDs, I'd consider returning them for a refund. They are obviously defective, as in significantly deviating from their advertised performance, either in speed or longevity.
Apparently the new firmware now advertises that it supports queued TRIM, when in fact it doesn't https://bugs.launchpad.net/ubu...
The old firmware did not advertise queued TRIM support, so it wasn't an issue. The solution is a kernel patch to blacklist queued TRIM on all Samsung 8xx drives.
It has no power loss protection, so now it could lose data much faster. It should be good for worthless data but that is all. I am not sure if it has at least small capacitors, the half-assed power loss mitigation technique which does not protect new flushed data, but at least prevents the loss of old, unrelated data.
Say you bought the 1Tb version (which is big for an SSD).
In this case, you rewrite it six times a year. That's 6Tb of write. That's...well... pathetic compared to the write expectancy of an SSD anyway.
So, actually, it's not that big a deal at all.
Use a copy on write filesystem, and make sure to image and reimage every 8 weeks. For optimal performance: heat up the NAND chips but cool down the controller itself.
And vote with your money.
It's low enough that most users probably won't have any disadvantage from these additional writes, but it's not entirely negligible. "Write expectancy" of SSDs isn't really that generous. It's typically on the order of a few hundred complete writes. Samsung claims an expected lifetime of close to 30 years for typical workstation loads. Over that time, 180 complete writes is a significant portion of the expected write endurance. Now, I wouldn't expect any of these drives to still be in use in 2045, but just because the downgraded life expectancy is probably still good enough for most people does not mean it's not a significant downgrade.
Apparently the new firmware now advertises that it supports queued TRIM, when in fact it doesn't https://bugs.launchpad.net/ubu...
The old firmware did not advertise queued TRIM support, so it wasn't an issue. The solution is a kernel patch to blacklist queued TRIM on all Samsung 8xx drives.
Whoa there! The Samsung 840PRO in addition to all the 850 series were not affected by this issue. You are painting with a very wide brush. I sincerely hope this is not the kind of decision-making that makes its way into the Linux kernel (though I suspect that is sometimes the case).
2045? Really? How many hard drives do you have running from 1985?
I still have one, but it requires 1.21 gigawatts.
Get free satoshi (Bitcoin) and Dogecoins
Goodness me.
We had this problem back in the 1970s/1980s with floppy disks!
When the disc drive writes to a part of the surface of the disc it energies the magnetic particle to saturation. This ability of the material to keep so much of its original pulse of energy was called the clipping level of the floppy.
As soon as the area is energised, it starts to decay (hopefully) very slowly over time. Once it decays below 40% of the energy originally given, that bit is lost and data is lost.
Some cheap floppies had a nasty low clipping level as they'd use cheap materials, over time of say a year the area that hasn't been rewritten to would decay and that bit was then unreadable. You lost that data. We had various programs that would take the 8", 51/4" and 3.5" floppies and read then rewrite the entire disk to ensure that the disc was refreshed. As I worked in Ferranti for the UK space and military, I could ask the likes of TDK,Maxell, etc. what the clipping levels of their discs were. Something the public didn't have access too.
If the sellers wouldn't say, we simply didn't buy from them. Let me tell you most low-medium priced suppliers hide this value and we didn't do business. Glad to say the top disc suppliers were always open and we'd buy discs with an over 80% clipping level!
With these MLC SSDs the voltage level is very important. It'll decay over time, nothing can stop it.
Admit you're wrong and fix the vanilla 840s and OEM devices based on the same or similar firmware/NAND. Keep mistreating customers and they will leave. This is not the smart tv market with average joes not caring. Most SSDs are purchased by pros, are specced en masse for machines by pros, or by well informed enthusiasts, Treat this customer base ill at your peril.
Silence is a state of mime.
Can you read? I said I don't expect any of the drives to be in use for 30 years, but the 30 year lifetime isn't a claim I made, that was Samsung's. Anyway, let's say you expect to use it for 7 years. That's not an unrealistic expectation. Over that time, 40 additional full rewrites amount to 5% of the total expected write endurance of the drive. Not a big issue, but not nothing either. I'm sure Samsung would object if all their customers came up 5% short on their end of the deal. And besides, a full rewrite of a 1TB SSD every two months isn't negligible from a power consumption point of view in a mobile device, because these additional writes will occur at times when the drive would normally be idle. That is 17GB of additional writes per day and roughly doubles the typical total writes of a desktop system.
Seriously. How does this kind of knee-jerk bullshit get modded +5 informative?
I'm still getting 10mb/sec sec on samsung 840. they have released no fix. only for evo :(
Say you bought the 1Tb version (which is big for an SSD).
1Tb was big maybe five years ago for an SSD, but these days pretty much every SSD-based laptop has that much or more. If you want to go big now, 1TB is around where you'd look. Or 1TiB. But not 1Tb.
You obviously failed to get his point.
We have a bunch of shared build PCs with 840 Evo SSDs in them and we noticed strange problems when we build off the SSD (over say, the HDD).
Basically what would happen after a little while (a month), all of a sudden during the build the entire system would practically lock up - all the cores are pegged at 99% system time, and system responsiveness collapses - it can literally be minutes for the system to respond. It makes a little headway, but compilation speed drops (since 99% of every core is spent in the kernel). It's completely fine off the hard drive, and if it wasn't for this loss in speed, the SSD would be faster (right now because it pauses a few minutes every 15 or so, the HDD is faster).
It's completely unusual - I did try to analyze the kernel, which appeared to have all the cores tied up in ext4 spinlocks. Not sure if it's a result of the tables being slow and blocking or what.
It happens under high load - I normally set the build at 12 threaded builds (8 cores!). Thought at first it was Linux collapsing under the weight of the build, but it's actually the SSD. Building off hard drive on the system system is no problem at all.
Judging from the kernel's blacklist, queued TRIM does cause issues on quite a few SSDs, the 840EVO just did not announce that capability before the patch and now does (but cannot do it), and hence the problem. The kernel folks are now adding all Samsung 8xx to the blacklist, which will likely fix the issue. As Windows is traditionally behind in these areas it may just not use queued TRIM at all. I do hope that Samsung adds (more) Linux test systems to their qualification process now, though. Side-note: The 850PRO is apparently affected as well, but the kernel already blacklists it.
The conclusion here is that apparently getting SSD firmware right is a pretty big challenge and that SSD technology is still evolving. Also, not enough testing on Linux and likely not enough really smart people in the SSD firmware team. It is a learning process and the prevalent "clueless MBA bean-counter plague" will likely affect Samsung as well, just as it does any other large company.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
As Windows is traditionally behind in these areas it may just not use queued TRIM at all.
That is my suspicion as well. This is sooo often the issue with all sorts of firmware. Linux tries to implement cutting edge features by spec, but in practice the hardware makers just write everything against Windows spec. The hardware might announce ACPI 5.0 support or queued TRIM support, but the actual codepaths are stubs that don't work properly. When such hardware is used under Linux, unexpected error states can be encountered. Sad trombone.
Because the issue is in Samsung's general SSD codebase it would seem.
They released firmware XM02B6Q for the 850 Pro in February this year, only to pull it because it was bricking drives.
But that firmware also introduced queued TRIM support, something the SSD drive itself does not support!
Now we see the same with the new firmware EXT0DB6Q released for the 2.5" 840 EVO.
If that is not proof enough that Samsung does not know what they are doing and the kernel developers do I don't know what to say!
That and apparently many hardware makers do not test against Linux or do not do it well. As reverse-engineering what Windows does is really not easily possible, we will see things like this from time to time. I hope this will result in more and more public shaming, as that is the only way to make the bean-counters realize they are not investing enough effort.
The only good thing is that the Linux kernel folks are pretty fast to respond.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Oh come on, man. You should have done it in Authentic Western-Style Anonymous Coward.
Like this: "small b means bits you shithead".
Wow. I'm surprised how you take a crappy drive like that so easily. I bet you didn't pay the serious money they actually charged for it? And it's no cheapo brand neither; rather the self-declared Mercedes. ... just works. Sure it does!
And the prescribed maintenance is rewriting all data twice a month because it tends to be forgetful. What a fantastic piece of hardware! That is what we ought to discuss here; rather than if a brute-force workaround
I dunno if everyone is aware that Samsung pays through the nose yearly to get large numbers of all sorts of journalists of technical papers on free business trips to Korea, several days, all included: business class regular flights, 5*-hotels, all meals, to cover the regular launch of their latest and greatest SSDs, including visits to the factories.
No wonder that Samsung SSDs get hyped up after such incentives by the writers of those journals.
If in doubt: no fantasy, but an enjoyment that a family member of mine partakes in regularly, the 'SSD-man' of one of those hardware journals. And now you won't tell me that those expenses are not factored into the selling price.
Luckily, I bought a Crucial on his recommendation, though.
I think, AC is the adequate authorship in this particular case! ;-)
And the prescribed maintenance is rewriting all data twice a month because it tends to be forgetful. What a fantastic piece of hardware! That is what we ought to discuss here; rather than if a brute-force workaround ... just works. Sure it does!
No. The prescribed maintenance is to rewrite old data that hasn't been written to for 2 months, because it tends to be slow to read otherwise. No-one has reported data loss as a result of this.
Notice also, that all the reporting so far uses the artificial benchmarks to demonstrate the problem. In normal use, you'd be unlikely to ever notice, unless you're copying big old date files from one location to another.
Why do so many people seem to use these Samsung drives when they seem to have so many problems?
I never hear anything about Crucial SSDs; It would seem logical that those would be better than Samsung SSD's, no?
Sorry, my mistake: wrong wording. I didn't mean data loss, but serious slowdown.
'unless' what? Why so apologetic for Samsung? I still think you can't be affected, or you must be rich. If I pay four-fold for SSD, I won't find excuses for the manufacturer when the SSD is slower than a standard disk running on platters. Why would you? ... wait ... 100.000 seconds, that is some 30 hours? And this is still generous, assuming 10 MB/s; while some report even lower transfer rates.
Yes, my movie collection for example: some movies that i didn't watch for years. "Oh, sorry, Samsung 840!" when the movies stutter, or "oh, sorry, Samsung 840!" when copying close to 1 TB takes
Are you by any chance related to Samsung and try to stonewall criticism?
0. About half a year ago, performance at read of data not read for a long time is observed to degrade.
1. Samsung acknowledges this fact.
The work around is obvious to everyone with a common sense: re-read data with old access data. This would be no fix, but the work-around of choice.
2. Samsung offers a fix some months later. Immediate observation: this fix doesn't fix the problem.
Samsung asks for more time and promises a fix.
3. Some more months later, Samsung provides the 'fix', which isn't, but the almost obvious work-around: regularly re-write (!!) the data.
Conclusions:
4. Samsung has tried to find a fix during 6 months, but in vain. The final solution is a brute-force work-around.
5. Strangely, though, the obvious work-around, that is re-read the data regularly, is not chosen. Instead, the data are re-written. This points to
6. There is more than meets the eye, because the path of no-wear, lower power re-read is not taken, but the one that uses additional power and additional life-cycles. This can't be an oversight on the side of Samsung, but intentional.
7. Why? What is it that we all don't know? There must be additional problems (unknown to me, at least) for Samsung to take this path for the work-around.
Ugh.
So data drift starts happening at 8 weeks, and the old data starts going from 500 MB/s to as slow as 30 MB/s.The first update tried to use different voltages when trying to access the data so it'd be less slow, and now the second update continuously rewrites data in the background in order to keep it fresh. So the drive I bought a few months ago for it's low power usage, speed and reliability now has 2 out of the 3 compromised. I'm trying to find updated power usage statistics if it's constantly rewriting in the background, but not finding anything. Really wishing I'd picked up the Crucial m500 at this point...
Let the class action lawsuits start.
I think in this case this is really inexcusable. So, they've got this shiny new queued trim feature they'd like to announce support for. They know neither Windows nor OSX actually will use it. They decide to not test it with the only easily available system (linux) which does support it.
So how did they actually test it I wonder, if at all?
Maybe they used the same test equipment as Crucial does I guess... Took Crucial years to finally acknowledge it is broken on all their SSDs. But Samsung is even more stupid here, despite they know (or should know) this feature caused problems on ssds from other manufacturers, they decide to now support this feature (which almost noone really would have missed anyway), don't test it and to everybody's surprise it fails just the same. Mind-boggingly stupid...
Given that the kernel 4.0.2 blacklist lists Micron, Crucial and Samsung as broken for this feature, you may be on to something. I also completely agree on the stupid. It is likely more complex though: They may have tried to produce the firmware cheaper than possible, by having only semi-competent (cheaper) people on it and replacing technological insight with "processes". Would not surprise me one bit. The MBA-bean-counter plague is strong in the industry these days. Save a penny, lose a billion is the name of the game.
Fortunately, Linux Kernel development is still a meritocracy (user-space only very partially so, just look at systemd or Gnome....) and things tend to get resolved fast, and in full view of everybody. The fix is in next-20150511, and I expect will go into all other maintained kernels soon. And more conservative distros did not turn on TRIM anyways and are unaffected.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It's taking them ages to admit that the vanilla 840 has the same problem. Just like the silent data corruption firmware problem with their 2TB Spinpoint F4, which they purported to have fixed (just like the 840 EVO). Now before you mark me as a troll / flamebait, know that I do like some of Samsung's storage products. I have a bunch of 1TB Spinpoint F1, 1TB Spinpoint F3 and 512GB 840 Pro drives, all performing brilliantly and reliably.