If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. Registration is $1 to post on this forum. To start viewing messages,
select the forum that you want to visit from the selection below.

From what I've read, the SF controller doesn't tolerate high deltas on least/most worn "flash blocks", meaning that it starts shuffling static data when needed, don't know about other controllers, there may be some static wear-leveling but we'll probably never know.

I didn't think that any of the G2 drives could do static data rotation, although I have heard talk of it. For sure the X25-M can't do it, maybe the 320 can however.

12GB of data on the SF drive has only been written to once. If that 12GB of NAND could be swapped as the rest wears down it would extend the life quite a bit.

Without static data rotation the MWI will get to 0, but there will still be 12GB of unscathed NAND. That is a likely real life scenario as well.

@alfaunits
Whether the random data generator is producing 10MB/s or 100MB/s has nothing to do with writing randomly or not.

If you are doing it in the same thread as the actual writing it does, because the writing needs to wait on the generator.

The Areca can sustain those speeds until the cache is filled or as long as the array can sustain that speed, I was using a small array incapable of coping with that speed and thus it wasn't sustained. (it lasted for a few seconds)
The easy test is just to generate the random data without writing the data, that would tell the potential of the random "generator".

I did not even take Areca into consideration here, but just the bare CPU, memory and PCI-e link. If you do it in the same thread and you can send 1.5GB/s to Areca (does not matter what Areca does with it, it can ditch them even), that means the combined speed of generator and PCI-e link is over 6GB/s total (3GB/s each on average, so per second they can write at half of the average = 1.5GB/s). You have to agree that's... too much?
Are you generating the random bits in the same thread that does the writes, or is there a separate thread for them in the background? (I suggested a back thread already, you said you have no time, so I presume it's all done in the same thread).
I know you have "grr" mind reading my posts, but I am not trying to play smart - if the above numbers and thread assumption are correct, something is too fishy and the entire test is skewed.

Because I question illogical things. I want to know if you're doing a useful thing here or just wasting several SSDs with sequential transfers. And I know I'm not alone in that questioning.
GNU RNGs can barely do tens of MB/s, hardware RNGs don't do >500MB/s, so yes I am quite suspicious of the claim that without threads you get RNG performance that is fast enough compared to SSD speed to think it does not affect the overall "write" speed, i.e. not making this just sequential transfers overall.

To make a test, you have to assume it's valid. This looks invalid. But it's your money dumped on an SSD. If you do reach close to 200TB for the 40GB X25-M you'll just prove me right here

And if I am completely wrong, my sincere apologies. I don't pick random fights with people who have something to learn from, and you are one of them. Please consider it constructive criticism or my learnign curve.

The random generator test I did on the Areca wasn't being generated real-time, I never claimed it was, it's pregenerated.
The test on the Areca has nothing to do with this test, it was in a completely different manner but still using the same pregenerated formula.

If you are a programmer, write yourself a simple function that looks like this.

declare a buffer of 4MB and fill the buffer using

for I = low to high do
buffer[I] = random(255)

Write the buffer to a file, it will be incompressible.

The data written to the Intels are just filled with "garbage" from the stack, they don't do compression so why spend cpu power on them.
The speeds so far at writing is at the staggering rate of 30-50MB/s.
This is so simple that I can't believe you are questioning the test, it could have been done using a simple batch file just copying files and getting the same results.

Sorry then. I was under the impression all of them used random data, which is why I disliked the outlook. I did notice 0Fill for your Intel test, just forgot.

Originally Posted by Anvil

I don't think you've been reading this thread.

The random generator test I did on the Areca wasn't being generated real-time, I never claimed it was, it's pregenerated.
The test on the Areca has nothing to do with this test, it was in a completely different manner but still using the same pregenerated formula.

If you are a programmer, write yourself a simple function that looks like this.

declare a buffer of 4MB and fill the buffer using

for I = low to high do
buffer[I] = random(255)

Write the buffer to a file, it will be incompressible.

The data written to the Intels are just filled with "garbage" from the stack, they don't do compression so why spend cpu power on them.
The speeds so far at writing is at the staggering rate of 30-50MB/s.
This is so simple that I can't believe you are questioning the test, it could have been done using a simple batch file just copying files and getting the same results.

I had to guess a few of the inputs (especially for one_hertz) but even if you take out the highly compressed data the SF drive worked with for the first ~5TB it is still doing really well so far, especially considering data is now uncompressible with no let up for static data rotation.

Delta between most-worn and least-worn Flash blocks: 12
Approximate SSD life Remaining: 91%
Number of bytes written to SSD: 28,352 GB

Edit:

Another interesting snipet from the Intel forum:

"Read disturb refers to the property of Nand that the more a block of Nand is read, the more errors are introduced. A brief note about Read Disturb (and other various Nand properties) are discussed in this technical note from Micron: