Jump to content

Greatli

Members
  • Posts

    2
  • Joined

Reputation

10 Good

About Greatli

  • Birthday 10/17/1986
  1. This is BS. stop saying it fixes the issue if you don't know if it does. Okay so. Above say 50% drive utilization it is SUPPOSED to tank the speed. This is just a fact of life with dynamic SLC caching. Once the SLC cache is small, it has to fold data into the MLC/TLC NAND from the SLC which slows it down a lot. However, I, and a bunch of other people, experience this problem no matter what utilization %, TRIM status, power settings, Chipset Drivers, or motherboard the drives are plugged into.I got an RMA approval from seagate for my Firecuda 520. I'm just sending it back because the problem is not OS software. If you check the userbenchmark for my drive, the Firecuda 520 500GB, the write speeds and overall score directly correlates with Firmware Version (which the user is unable to update themselves. What you get from the factory you are stuck with). Least squares linear regression tells me that, like I suspected before, it is the Phison E16 Firmware. Each of the PCIe 4.0 drive manufacturers write their own proprietary controller firmware. Apparently Seagate's version 11 blows monkey balls compared to version 14. This seems to ring true no matter which company make/model 4.0 drive you have. Phison oversees the firmware writing process, but only provides a framework. I'm guessing that the first framework they provided, which is the one I'm stuck with, was ****-tier. I talked with u/New_Maxx from reddit. He still thinks that the problem is just inherent to all dynamic SLC cache drives, but it can't be 100% true. Under normal circumstances your drive will fill up the entire SLC-Cache (the empty space) on your drive. The space available should be 1/3d the size of your total amount of free space (SLC takes up 3x the space of TLC per byte). My drive is only 10% filled and can't get above 500MB/s (0,5GB/s) write for more than literally 2 seconds directly following a reboot and a drive trim. 500MB/s IS, however, the same exact speed you WOULD get if the SLC cache were full and the drive was folding SLC data into MLC/TLC. Something with their software is bad. With a drive utilization of 10%, I should have 420GB of TLC space, which equates to over 140GB of SLC cache. I should be able to get a sustained write of ~3GB/s for nearly a full minute instead of 2 seconds. Once again, the controller software is to blame. Nothing you do in windows should be able to affect it, unless your problem is that you have high drive utilization (50%+), which is normal. Its b0rked mates. Will they fix it? Probably not. The next generation of 4.0 drives are coming out emminently. Samsung's 980 pro will be out within a matter of weeks, along with Phison E18 which is a true PCIe 4.0 controller, unlike E16 which is just a bootstrapped POS PCIe 3.0 controller that they jury rigged into being able to work on 4.0 So don't expect a change unless you RMA.
  2. I signed up for the Corsair forums to let you guys know that I've been pulling my hair out wondering why my Seagate 520 PCIe 4.0 M.2 NVMe drive has only been getting 500MB/s read. I refuse to believe this is a SLC caching issue. I think it is a Phison E16 SSD Controller issue. I've been searching this problem all day and have seen that everyone that has had this problem is using an SSD that is on the Phison E16 controller. This is really aggrivating me. When the test begins the write speed jumps straight to 2k (where it should be), then plummets down to ~500 every time. It almost makes me wonder if the OS is seeing it as SATA 6Gbps.
×
×
  • Create New...