SpeedRead before/after SpinRite

  • Release Candidate 6
    Guest:
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.

Uri

New member
Sep 25, 2020
2
0
Hi, this is an SSD from Crucial with a few monts of ligth use. the speed readings allways was fluctuating and at higher resolution the more slow the drive appears... so I use SpinRite on it.

Pre SpinRite

Code:
Driv Size  Drive Identity     Location:    0      25%     50%     75%     100
---- ----- ---------------------------- ------- ------- ------- ------- -------
81  480GB CT480BX500SSD1                501.5   260.3   261.4   261.4   260.6

                  Benchmarked: Thursday, 2020-12-31 at 11:50

And this (/3 option without detail)
Code:
Driv Size  Drive Identity     Location:    0      25%     50%     75%     100
---- ----- ---------------------------- ------- ------- ------- ------- -------
81  480GB CT480BX500SSD1                111.5   101.2   101.7   101.8   175.2
---- ----- ---------------------------- ------- ------- ------- ------- -------
                  Benchmarked: Friday, 2021-01-01 at 20:38

Post SpinRite
(/3 option without detail)
Code:
Driv Size  Drive Identity     Location:    0      25%     50%     75%     100
---- ----- ---------------------------- ------- ------- ------- ------- -------
81  480GB CT480BX500SSD1                546.3   545.3   546.4   546.3   544.3
---- ----- ---------------------------- ------- ------- ------- ------- -------
                  Benchmarked: Saturday, 2021-01-02 at 12:22

The pc feels snappier.

Great job and thank you Steve and all testers.
 

Attachments

  • RS015.TXT
    21.1 KB · Views: 337
  • RS018.TXT
    21.1 KB · Views: 312
  • Wow
Reactions: Barry Wallis
Last edited:
Level 2 can already make a big difference
Yes, it's true, but it largely depends on the SSD's controller/firmware. I've been lead to believe that no current SSD controller will ever do a write without being explicitly told to do so. I do believe that spinners have a different view on this, and if they encounter a hard to read sector, they will proactively fix it if possible.
 
People should stop comparing spinners with SSD. SSD drives shuffle data around all the time. Now assume a read is troublesome because host requests data that has been sitting for a while and some bit errors creeped in. Firmware may need ECC or even RR to retrieve the data, it will then write data to new location (since it can not refresh in-place) and add original blocks to garbage collection queue. If we now read the freshly written data it will not have to go through error recovery => improved result.

At some point garbage collector routines will erase original blocks and if successful there's no reason to add it to any grown defects list. This explains how a read-only scan can still result in an improvement.
 
SSD drives shuffle data around all the time.
Only on write, and that is the issue. People are used to HDDs doing things on reads (such as failing a sector/cluster and marking it bad.) SSDs are not doing any changes on a read. They're free to change whatever they like on a write, because that is expected, but no one expects a read to reduce the write lifetime of the SSD.
 
Only on write, and that is the issue.

Nope, that's simply wrong. Garbage collection happens all the time and shuffles data around all over the place.

Marking clusters is done on file system level, something totally different. Has nothing to do with it.

Yes, it does write, even if you don't want it to, starting already with write amplification. And although you want to minimize additional writes, if an SSD has trouble reading but can recover the data using ECC and RR, then of course it will assign data to a new page to preserve it, it would be criminal not to. It's a trade off, sacrifice write/erase cycles for intact data. It's a no brainer.
 
Last edited:
I have some notion of the concept and I will try:

RR is a method built into flash to deal with what Steve refers to as cell drift. Imagine a cell being a bucket of water with a marker half way that decides if we're dealing with a zero or a one. Assume water leaks out at a very slow rate so that relative to our threshold marker the value flips (a bit error).

Now assume we have a grid of buckets that make up a sector, each representing a zero or one that we leave alone for a while and water slowly leaks, or maybe even some gets added, spilled from filling adjacent grids of buckets . Then ECC tells us the value of the grid of buckets changed to a degree where we can not calculate original value. And that's where RR kicks in.

The way I understand it the threshold for all buckets is lowered/increased, data is read, now we determine if we have less bit errors (again using ECC). So basically the idea is to find a common threshold that produces optimal result, the least amount of bit errors. Using this method it is often possible to get rid of all bit errors. Note that my experience is with flash drives and memory cards, but these are the same chips essentially as used in SSDs. This is done by the firmware itself.

This video shows how data recovery software can emulate the controller and 'play' with thresholds by modifying RR registers to read NAND without the controller:

 
@DiskTuna Wow. Thanks for that cool info. All that really scares me, and doesn't give me confidence. From my (not a chip designer) point of view, continually redefining what is a "1" and what is a "0", particularly in multi level cells, sounds really dangerous. Simplistic example. Bucket 1/2 + .0001 full. Ok it's a 1. Bucket is leaking (as you said). Bucket is 7/16 full. Ok it's still a 1 (from ECC). Bucket is 6/16 full. Ok it's still a 1. ... Bucket is 2/16 full. ???? What is it? Like I said, simplistic. But, it sounds like it won't end well. Lends credence to the idea of doing full rewrites a couple of times per year as we've been discussing. I always think it's better to keep data, than to restore data, or lose data.

May your bits be stable and your interfaces be fast. :cool: Ron
 
@DiskTuna Wow. Thanks for that cool info. All that really scares me, and doesn't give me confidence. From my (not a chip designer) point of view, continually redefining what is a "1" and what is a "0", particularly in multi level cells, sounds really dangerous. Simplistic example. Bucket 1/2 + .0001 full. Ok it's a 1. Bucket is leaking (as you said). Bucket is 7/16 full. Ok it's still a 1 (from ECC). Bucket is 6/16 full. Ok it's still a 1. ... Bucket is 2/16 full. ???? What is it? Like I said, simplistic.
Yeah well, key is ECC we have to compare with. So we can read a page with RRx and verify with ECC. Less bit errors is better. Often can be brought down to zero bit errors. For example in this fragment you can see green vs red blocks according to ECC while experimenting with different thresholds:

And note that the firmware can do this all by itself, the software is only emulating a controller because the chip was unsoldered. Again this is a NAND chip from a flash drive but same chips as used on SSDs.
But, it sounds like it won't end well. Lends credence to the idea of doing full rewrites a couple of times per year as we've been discussing. I always think it's better to keep data, than to restore data, or lose data.
Agreed! But what I find fascinating is see if we can determine if for example only reading (level 2) can bring the result we want. And if this appears to be so to a degree, can we explain it perhaps.
 
  • Like
Reactions: rfrazier
@DiskTuna Wow. Thanks for that cool info. All that really scares me, and doesn't give me confidence. From my (not a chip designer) point of view, continually redefining what is a "1" and what is a "0", particularly in multi level cells, sounds really dangerous. Simplistic example. Bucket 1/2 + .0001 full. Ok it's a 1. Bucket is leaking (as you said). Bucket is 7/16 full. Ok it's still a 1 (from ECC). Bucket is 6/16 full. Ok it's still a 1. ... Bucket is 2/16 full. ???? What is it? Like I said, simplistic. But, it sounds like it won't end well. Lends credence to the idea of doing full rewrites a couple of times per year as we've been discussing. I always think it's better to keep data, than to restore data, or lose data.

May your bits be stable and your interfaces be fast. :cool: Ron
Spinning magnetic disks have the same thing going on...not every '1' bit is the same level of magnetization, it has to be above a certain level to be considered a 1. You can see that happening if you look at the raw data display in spinrite, where it shows the square waves it's getting off the read/write heads...the '1' levels vary quite significantly...it's not something new, or an issue with just SSD's...it's digital data being stored in an analog world.
 
Spinning magnetic disks have the same thing going on...not every '1' bit is the same level of magnetization, it has to be above a certain level to be considered a 1. You can see that happening if you look at the raw data display in spinrite, where it shows the square waves it's getting off the read/write heads...the '1' levels vary quite significantly...it's not something new, or an issue with just SSD's...it's digital data being stored in an analog world.
Yeah in the end we read analog data. Problem is that modern drives no longer allow for this kind of tinkering. Nor do flash drives for that matter. Video where RR registers are modified and then resulting read is evaluated against bit errors using ECC are against the 'naked' chip, so with controller out of the way. So the equivalent to taking platters out of the drive, hooking them up to a reading apparatus controlled by software to move the heads around. Although the latter is of course a lot harder.
 
All of this reminds me of a book I was reading about quantum programming recently, which discussed how slight variations in the "values" of the qubits can result in vastly different results, even floating-point numbers, as well as exponentially-increasing numbers of mundane, ordinary bits.

Sorry for the OT post.
 
All of this reminds me of a book I was reading about quantum programming recently, which discussed how slight variations in the "values" of the qubits can result in vastly different results, even floating-point numbers, as well as exponentially-increasing numbers of mundane, ordinary bits.

Sorry for the OT post.

I would say slight;y tangential rather than off topic. :) And super interesting! :)