|
Mr. Ali posted:Where did you hear about this? I can't find any information on this with a quick Google search.
|
#
?
Sep 7, 2014 19:28
|
|
|
|
| # ? Jun 1, 2024 19:08 |
|
|
Alereon posted:It's actually the SM951. It's the OEM drive based on the new controller that will likely be released in a consumer version before too long. Very cool, can't wait to purchase these. Not worried about the OEM only part, we sourced some XP941 earlier this year via overseas sites.
|
|
#
?
Sep 7, 2014 20:13
|
|
|
can you strap a bootloader to a different drive to boot into win7, or will it just not work without win8? Assuming of course the mobo is compatible.
|
|
#
?
Sep 7, 2014 22:22
|
|
|
I forgot if I posted about this already... Crazy idea: Could running defrag on an SSD help with wear-leveling (or prolong its life)? Think about a 240GB drive. You install your OS, programs, and games to it. ~100GB of data is written to NAND. It uses 1 write cycle for that NAND. The remaining free space is then used for all further writes. Browser cache, downloaded apps and media, and so on. The remaining ~140GB gets written to over and over. Wear-leveling just keeps cycling writes on that same ~140GB of "free" space, while the original ~100GB of NAND rarely changes or gets written to again (since it has semi-permanent data already saved there). The SSD goes through several write cycles. Dozens, hundreds, etc., all the while the first NAND remains at just 1 write cycle. You'll end up with a drive where half the writes might be used up on only half the drive. Defragging will write a new copy of each file it changes to a new part of the SSD. The original file location will get marked deleted, free for another write. It uses write cycles, but helps with wear-leveling. Part of the SSD test and prep we do at work is filling and wiping the SSD twice, to ensure every bit of NAND has been written to at least once (we've had several SSDs fail during this part, making it easy to weed out some bad drives before putting them into production). We know that once we put an OS on them, that part of the drive will see very little change over the next 5/10/15/20 years, but the rest of the drive will be written to thousands of times. Short of taking the system down to format & reinstall, running a defrag seems like the only way to move some of that data around to take advantage of wear-leveling.
|
|
#
?
Sep 9, 2014 01:39
|
|
|
Pretty sure modern firmware actually moves static data around as a part of wear leveling. This is completely invisible to the OS, though.
|
|
#
?
Sep 9, 2014 02:08
|
|
|
Yes, that's also my understanding of wear leveling. Even static data is moved around to keep all of the NAND roughly being used equally. From what I understand as well, defragging an SSD is a great way to blow through its write cycles quickly for no gain. As shown in (techreports?) endurance test, even if you were only re-writing the same 140gb, its still going to last well beyond what anything short of a database server is going to put it through.
|
|
#
?
Sep 9, 2014 02:12
|
|
|
OK, is static wear leveling part of standard SSD functionality, then? I've read almost nothing about it. I've only read about dynamic wear leveling. Lots of info on how new writes are done to the next cell. Not a lot of info on old data being moved.
|
|
#
?
Sep 9, 2014 02:31
|
|
|
Modern SSD firmware may even move static data around in the background without being forced to by write activity. Recent flash memory process nodes often have fun issues like read disturbance, neighbor write disturbance, fade, and so on. If a block starts showing high raw error rates it'll decide to migrate the contents elsewhere before the error rate gets too high for correction to fix. This is why you want to have your SSD powered at least some of the time if you're concerned about long term (multi year) data retention. The controller needs to have a chance to do background maintenance. In a sense it's a very slow form of DRAM refresh.
|
|
#
?
Sep 9, 2014 02:44
|
|
|
The species has been around 200,000 years and still the best way we save stuff for a long time is by making marks in stone.
|
|
#
?
Sep 9, 2014 03:11
|
|
|
Xenomorph posted:I've only read about dynamic wear leveling. Lots of info on how new writes are done to the next cell. Not a lot of info on old data being moved. There's not much distinction between static and dynamic, it's more about monitoring each block's status and acting appropriately. Whenever a block's lifetime erase count drops too far behind the rest, the drive migrates its contents to free blocks with higher erase counts, erases the original block, and puts it at the front of the free list. Keep in mind that there's no fixed mapping between the sector numbers your computer knows about, and where data is physically located. Manipulating its own internal location map lets the SSD provide true wear leveling while presenting the illusion of static data location to the host computer and OS.
|
|
#
?
Sep 9, 2014 03:33
|
|
|
Alereon posted:Fresh installation (recommended): (Optional: Verify the system can complete at least one full pass of Memtest86+ and update the motherboard BIOS.) Ensure the SATA controller is set to AHCI mode in the BIOS. Disconnect all other drives and connect the SSD. Many motherboards have SATA ports provided by chips from different vendors, consult the manual to confirm you are connecting the drive to a SATA port provided by the chipset, either Intel or AMD. Install Windows, then install the latest chipset drivers from the manufacturer's website (Intel or AMD), then the latest AHCI drivers from the manufacturer's website (Intel or AMD). Intel calls its AHCI drivers "Rapid Storage Technology" software. Trying to update the Chipset Drivers after a fresh install (the AMD ones include the AHCI in them: http://support.amd.com/en-us/download/chipset?os=Windows+7), it requires a restart upon them finishing and: posts, reboots (at the Windows logo screen), requires repairing Windows 7/booting in safe mode, and then I'm back to the fresh install after accepting the restore point to repair it. Giving Google a go I saw that: AMD removed the AHCI update from their newest non-beta video driver package (Catalyst 14.4, same version as the Chipset Drivers... the current beta video drivers [14.7] also do not include an AHCI update) because it was causing problems (they state capability with some motherboards is the issue) and people saying that choosing to not do the AHCI driver update while running the Chipset Drivers should not screw up windows. I did the latter and, sure enough, it starts fine with all the other Chipset Driver update content and no AHCI update. So, how important are the latest AHCI drivers (baring in mind I did install Windows with my BIOS set to AHCI so I have some form of AHCI drivers... ones that work at least)? Is there a way I can find what version the AHCI drivers I have so I can see if I can find older AMD AHCI drivers that don't break Windows (but are newer than whatever there is currently)? Thanks for any useful info in advance; I guess the most pressing concern is whether or not older AHCI drivers will interfere with TRIM/other goodies or if it'll just mean not as good performance. bUm fucked around with this message at 06:09 on Sep 9, 2014 |
|
#
?
Sep 9, 2014 06:07
|
|
|
AHCI drivers are not critical, if you can't get the AMD drivers to install the Windows-provided drivers will work and support TRIM. There is some loss of performance, but it's not huge.
|
|
#
?
Sep 9, 2014 06:46
|
|
|
Factory Factory posted:Which boot problem? If you mean basic support, Intel 9-series boards have been/are being validated to boot against PCIe drives like the Samsung XP941, since these boards have SATA Express port options. Bottom line, booting is a driver issue, both in the OS and the firmware. For OS support, Windows 8.1 added driver support for booting from NVMe drives, so that's set... as long as you have Windows 8.1. 9-series boards either have PCIe/NVMe boot support already, or the appropriate BIOS updates are in development. That must be it, the last time I read about it was a while ago before the win8.1/9 series release. Thanks for clearing that up. I guess that's another way to get people to install windows 8.1 
|
|
#
?
Sep 9, 2014 10:06
|
|
|
http://www.overclock.net/t/1507897/samsung-840-evo-read-speed-drops-on-old-written-data-in-the-drive What's all this about? Doesn't sound good
|
|
#
?
Sep 11, 2014 04:52
|
|
|
thegoat posted:http://www.overclock.net/t/1507897/samsung-840-evo-read-speed-drops-on-old-written-data-in-the-drive Alereon fucked around with this message at 05:47 on Sep 11, 2014 |
|
#
?
Sep 11, 2014 05:37
|
|
|
I've seen the exact same thing. Funnily enough, it was also with some old virtual machines like in that linked thread. At the time, I figured it was a bad cable, or system misconfig , or something and moved on with my life. Like Aleron, I'd like to see AnandTech look into it.
|
|
#
?
Sep 11, 2014 08:12
|
|
|
AnandTech has been notified: https://twitter.com/kristianvatto/status/510004403991228416
|
|
#
?
Sep 11, 2014 11:08
|
|
|
Uh, wouldn't the static wear-leveling negate the "issue" of having data sit on the same NAND? Some on that forum said that they did get some performance back after they ran a defrag on the drive or manually recopying the data (forcing it to new cells).
|
|
#
?
Sep 11, 2014 13:52
|
|
|
Xenomorph posted:Uh, wouldn't the static wear-leveling negate the "issue" of having data sit on the same NAND? Some on that forum said that they did get some performance back after they ran a defrag on the drive or manually recopying the data (forcing it to new cells).
|
|
#
?
Sep 11, 2014 13:54
|
|
|
Ugh, I was just about to put down some cash for an 840. That's a real bummer. Sounds like a software issue, are samsung good about fixing these these issues? Perhaps I should just hold on for the 850?
|
|
#
?
Sep 11, 2014 15:09
|
|
|
Is this serious enough that we should be telling people to hold off buying EVOs when they ask in the part picking thread?
|
|
#
?
Sep 11, 2014 15:20
|
|
|
The Lord Bude posted:Is this serious enough that we should be telling people to hold off buying EVOs when they ask in the part picking thread?
|
|
#
?
Sep 11, 2014 15:24
|
|
|
Alereon posted:If anything it's more likely to be related to that wear levelling process, not actually the fact that data has been sitting for some time. Do you mean that the drive might be using the opportunity afforded by a requested read of "old" data to rewrite it elsewhere? I guess that would make sense and be nothing to really worry about.
|
|
#
?
Sep 11, 2014 18:24
|
|
|
It might be good to at least preface any recommendations in the Parts Picking Thread with a comment on this issue and telling people to come to this thread, so that if it does appear to be exclusive to the 840 EVO (and possibly 840) series no one comes back upset about the recommendation.
|
|
#
?
Sep 11, 2014 22:08
|
|
|
Well that's somewhat troubling, especially since that's what I ended up purchasing a month ago.
|
|
#
?
Sep 12, 2014 15:59
|
|
|
everythingWasBees posted:Well that's somewhat troubling, especially since that's what I ended up purchasing a month ago. I also just picked up an Evo 840. Perhaps it's something that could be corrected with a firmware update if it becomes widespread?
|
|
#
?
Sep 12, 2014 17:11
|
|
|
thegoat posted:http://www.overclock.net/t/1507897/samsung-840-evo-read-speed-drops-on-old-written-data-in-the-drive Glad I went with the 480GB Intel 730 instead of the 500GB EVO when the 730 was marked down to the same price. Dick Fagballzson fucked around with this message at 19:12 on Sep 12, 2014 |
|
#
?
Sep 12, 2014 17:53
|
|
|
I have a 256gb Crucial M4 that I haven't been real great about not keeping over 20% free though I typically don't go below 10% free, if ever. I saw in the OP that this can degrade performance, sometimes permanently without a drive wipe?, so I was curious how I would determine if my drive was suffering from this? Run a benchmark tool and compare to what the drive should be doing?
|
|
#
?
Sep 12, 2014 18:01
|
|
|
Raymn posted:I have a 256gb Crucial M4 that I haven't been real great about not keeping over 20% free though I typically don't go below 10% free, if ever. I saw in the OP that this can degrade performance, sometimes permanently without a drive wipe?, so I was curious how I would determine if my drive was suffering from this? Run a benchmark tool and compare to what the drive should be doing?
|
|
#
?
Sep 12, 2014 18:05
|
|
|
Alereon posted:The drive will only get stuck in a low-performance state if its run with very low free space for an extended time. Just free up some space and run a TRIM pass, either using the Windows 8 disk defragmenter, or ForceTrim. I have Windows 7 but I assume the disk defragmenter would accomplish the same thing?
|
|
#
?
Sep 12, 2014 18:40
|
|
|
Alereon posted:The drive will only get stuck in a low-performance state if its run with very low free space for an extended time. Just free up some space and run a TRIM pass, either using the Windows 8 disk defragmenter, or ForceTrim. The more I think about this, the more I lean towards it being a translation table caching/indexing issue. The data is there in nvram, and all the nvram is rated to perform identically, but it seems like the step of translating LBA to pagetable location is taking much longer than it should. Anything that causes the lookup table to be rebuilt seems to fix it, even when the data is just moved from one identical performing location to another. If we were seeing data recovery errors or allocation errors or spare space consumption, then it would be worrisome, but the smart stats don't show that. The way the drive functions internally is so black box though, it's really impossible to tell, even for an expert end user. Hopefully Samsung doesn't ignore the issue.
|
|
#
?
Sep 12, 2014 18:46
|
|
|
Raymn posted:I have Windows 7 but I assume the disk defragmenter would accomplish the same thing? EoRaptor posted:The more I think about this, the more I lean towards it being a translation table caching/indexing issue. The data is there in nvram, and all the nvram is rated to perform identically, but it seems like the step of translating LBA to pagetable location is taking much longer than it should. Alereon fucked around with this message at 18:50 on Sep 12, 2014 |
|
#
?
Sep 12, 2014 18:48
|
|
|
I was always concerned about the cheap TLC NAND the EVOs use. Kind of reminds me of the OCZ SSDs a few years ago: cheap, super fast in benchmarks, and designed to turn heads and sell like hotcakes, but also using cheap NAND and totally unreliable in the long run. You get what you pay for I guess? Also I don't think the EVOs were ever meant for anyone other than light users. The problem is a lot of power users at hardware enthusiast forums were buying and recommending the EVO above everything else, which I had a gut feeling was a big mistake, and it's looking like I was right. The same thing was happening with cheap OCZ drives a few years ago. People never learn. The name of the game with SSDs is you either pay to play or you wait and catch a good deal on the high-end normally expensive poo poo. Dick Fagballzson fucked around with this message at 20:40 on Sep 12, 2014 |
|
#
?
Sep 12, 2014 20:30
|
|
|
This has nothing to do with the NAND. TechReport has written nearly a petabyte to an 840 vanilla and it's performing exactly as expected - well above the numbers being listed here. This is something weird, somewhere else.
|
|
#
?
Sep 12, 2014 20:59
|
|
|
A sales guy from OCZ convinced one of my program managers to let him drop by Monday. My immediate reaction is hell no. Are they as bad as I remember?
|
|
#
?
Sep 12, 2014 23:30
|
|
|
They're owned by Toshiba now, but they haven't really improved their products yet either. You probably don't want anything he's selling.
|
|
#
?
Sep 12, 2014 23:34
|
|
|
EoRaptor posted:The more I think about this, the more I lean towards it being a translation table caching/indexing issue. The data is there in nvram, and all the nvram is rated to perform identically, but it seems like the step of translating LBA to pagetable location is taking much longer than it should. Could be. I also like the theory (forget if I saw it here or elsewhere) that it might be bad data placement. Individual flash die are surprisingly slow. SSDs can only get to ~500MB/s by doing the moral equivalent of RAID 0 across all the die, so data placement is very important for performance. When writing new data, the SSD will naturally interleave it across all die. (If it doesn't it won't be able to hit 100s of MB/s in linear write benchmarks.) This sets the drive up for good read performance later on, particularly if it's linear data that will be read back in linear order. But what if wear leveling sometimes concentrates old data on just a few die as a side effect? Read performance will suffer.
|
|
#
?
Sep 13, 2014 00:15
|
|
|
Dick Fagballzson posted:I was always concerned about the cheap TLC NAND the EVOs use. Kind of reminds me of the OCZ SSDs a few years ago: cheap, super fast in benchmarks, and designed to turn heads and sell like hotcakes, but also using cheap NAND and totally unreliable in the long run. You get what you pay for I guess? lol where do some of you get this stuff
|
|
#
?
Sep 13, 2014 00:24
|
|
|
go3 posted:lol where do some of you get this stuff He defied Alereon's advice to just get an EVO and now he's all  about it. Curious to see how the situation develops since I just put an EVO in my laptop. The issue seems kind of overblown, though. 
|
|
#
?
Sep 13, 2014 00:41
|
|
|
|
| # ? Jun 1, 2024 19:08 |
|
|
I defied his advice, went with my instincts, and turned out to be right. And I'll be smug about it all day long thank you very much. I also bought a second Intel 730 at the $262 price just to spite everyone here. My 730s will still be humming along nicely years from now while your EVOs are in the dumpster. Dick Fagballzson fucked around with this message at 01:14 on Sep 13, 2014 |
|
#
?
Sep 13, 2014 01:11
|
|