SpinRite

[Joep]

Again, I have pointed this out several times before in GRC newsgroups. Not just only recently but even during SR6 development stage. Now granted I did so to anyone making some statement about SR having super-low access to the drive, or secret patterns, or worst case scenario patterns etc., not per se to SG. Same with nonsense about off-track reads for example, I tell them that drives themselves do this, I even give them links to IBM document about their drives and error recovery ..

More recently I asked SG specifically to back up claims, example (https://www.grc.com/validrive/the-report.htm):

"Writing to NAND flash memory requires the generation of high voltage, but reading requires low voltage. Before any NAND chip can write data into NAND flash memory it must internally generate a high voltage. This uses a “voltage pump” which takes time to charge up, and lower-end solid state storage does this much more slowly. Then, before reading, that high voltage must be dumped.

Since operating systems typically write entire files and even multiple files at once, a single “voltage charging” cycle can be amortized across the entire large write. So large writes are able to proceed at a reasonable pace. But since ValiDrive only writes 4k bytes before reading it back, causing the “writing charge” to be dumped before each read, ValiDrive accentuates this delay for drives which require a long write-cycle."

Now arguably I am not an electronics expert but I can think of various reasons why writes are slower than reads, so I gave some of those and asked how he became so convinced "voltage pumps" (I think they're mostly referred to as charge pumps, but anyway) are a major factor. As far as I can tell the charge up periods for charge pumps are in us ranges and could only partially explain why writes & erases are slower than reads. Happened twice, his answer: "experience".

One more: SG keeps attributing stuff like bit errors in NAND to read-disturb while research I have on it shows retention errors are main contributing factor. I have addressed this serval times. For last time I actually do have URL, https://forums.grc.com/threads/srpr-spi ... /post-9605. He still tries 'spinning' it.

[Joep]

Found the charge pump discussion but it's a newsgroup, no idea how I can link to it ..

Me:

> I know what it is but disagree with the analysis. There's many
> variables that can affect write speeds, I have no clue why
> Steve singles out this as main contributor to slow write
> speed.

Steve:

Why? Experience and evidence. Now is not the time for me to
dwell on this. But it would be easy enough to test and once we
move to SR7 I think that characterizing a NAND drive's read/
write switching speed would be interesting.

Me (again):

How would you test that? And what evidence is that? It's got nothing to
do with dwelling over IMO, just backing up a firm claim with the
necessary evidence. And I am genuinly curious, if charge pump are such
major contributors I'd like to know.

There are multiple factors that could contribute to slow writes, and
some of those being so obvious that I personally wonder why those are
dismissed or not mentioned.

As an example read/program/erase time of MLC NAND chip is on average
2-3 times slower compared to a SLC NAND chip (for example SLC program
time 200-300 us vs MLC 600-900 us). So, one obvious answer to why UFD A
is slower than UFD B would be, the NAND type that is being used.

If we compare MLC to TLC on average the TLC chip needs 50% more time to
perform a read/program/erase operation. While this may be small beer
with regards to read speed typically meaured in microseconds, erase
speeds are measured in milliseconds and then a 50 - 100% more or less
time required to perform an operation becomes a much bigger factor.

As far as I can tell and find in literature and research, performance
of charge pumps as embedded in NAND chip dies, for example the charge
pump starting up, is typically in microsecond ranges (1-5 us).

Anyway, with that in mind I can not compute why you'd single out the
charge pump as major contributing factor when explaining slow USB flash
drives. And then we haven't even touched processor (controller) speed,
layout of the NAND, error correction algorithms etc.. We only need to
look at two controllers potentially used on any given flash drive from
a brand like SiliconMotion to see day and night performance differences
for example 130 MB/s vs 350 MB/s read speeds.

I can not even imagine how you could measure the contribution of the
charge pumps vs. contributions of all other factors involved.

Steve

... silence.

[CrazyTeeka]

I'm back from weekend travels! Soo tired.

[Joep]

The "voltage pump" or someone believing that it is a major issue is fine, but when SG says it people start taking it as truth. Example: https://forums.grc.com/threads/validriv ... /post-9436

Maybe Franc knows if it has any merit? @fzabkar

[fzabkar]

I confess that I don't know much about what happens inside the NAND flash. I do know that many Samsung SSDs have an external 12V boost voltage for the NAND. Micron's Fortis Flash datasheets refer to an external 12V Vpp supply, but there is no discussion about the use of this supply or the internal charge pumps. A Jedec standard defines the voltage levels and ball-out for Vpp, but it does not define its use, leading me to believe that IC makers can choose to do whatever they like with it.

This TI article talks about using an external 12V boost supply instead of the internal charge pump:

https://e2e.ti.com/blogs_/b/powerhouse/ ... -converter

ISTM that, if Samsung's SSDs are using an external ever-present programming voltage, and if what Steve Gibson says is true, then they should have significantly better "bursty" write performance than their competitors.

In any case, Steve Gibson should at least have compared the sustained write performance between the two drives, just to see if there was an underlying issue with writing.

The other question I have is, what constitutes "lower-end solid state storage"? There are only a few NAND chip makers, and the difference between their low and high end chips seems to be related to yield rather than fundamental differences in design. For example, many cheap storage devices use Spectek NAND, which is second grade Micron stuff. I can't imagine that their write performance would differ.

http://www.hddoracle.com/viewtopic.php?p=23002#p23002

Edit:

I suppose the really cheap junk might contain repurposed EMMC, MCP, etc. ChipGenius should be able to tell.

[Joep]

Thank you.

I find it very hard to get info on this topic, it's various bits and pieces, some research n improving charge pump efficiency and reducing real-estate, or space needed by it in NAND, but them not mentioning the time to charge the pump etc., some Google patents mentioning values like 1 to 5 micro-seconds which suggests they of course are a factor but not that big of a deal.

But I like your argument that NAND is NAND, and low cost NAND is simply the same NAND that does not meet some specification threshold (if I got that correctly).

[CrazyTeeka]

All caught up on what happened over the weekend.

Going to use hash values to compare some files before and after a level 5 scan.

Going to use a fill pattern of "FF" to check if that firmware bug occurs when reading good sectors.
R-Studio can search whole drive for bytes that are not "FF".

UK based lab agreed to clear g-list for me which should bring those 81 bad sectors back.

I really hope that Steve has listened to all the feedback, and changes to safer practices over historical practices.

[CrazyTeeka]

Drive seems to read fine once good spares have been swapped in. I guess that means firmware issue only manifests with bad sectors?

Searched whole drive for hex values that are not "FF":

Screenshot 2023-11-21 123935.png (51.28 KiB) Viewed 39868 times

Checking that 2 specific sectors read back the same data that was last written to them:

Screenshot 2023-11-21 124712.png (57.9 KiB) Viewed 39867 times

[CrazyTeeka]

Using a different drive, I'm checking that the file hash remains the same before and after a level 5 scan.
Test should confirm that a level 5 scan does not corrupt user's data on a good drive.

[Joep]

But do they occupy suspect sectors?