GPU ECC Correction

[Sasha Sheremetov]

Hi folks,
I'm happy to announce, we have finally tamed parallel computing technology on GPU and re-invented ECC correction process!
For a starter, we have added a single-GPU usage for ECC/BCH correction into VNR 4.0 software update.
Our tests show that it's possible to achieve 8-10x time decrease (performance increase?) for ECC correction now, especially on longer ECC codes (short ones are easy for GPU to compute so most of the time it's I/O of VRAM - SSD that consumes time).
Haven't tested it on RTX30xx yet though, hope will do soon (but I can project ~30x increase on those cards).
Check HERE for mode details.

My personal feedback (or feelings?)
Honestly, I personally feel like a huge relief after years of pain....when I tested it first time on a decent GPU, I got shocked (and I've seen a lot during my RnD years!) and had a very stupid smile on my face. One problem less...

For non-gamers/non-miners:
Even built-in GPU like in Core i7 can make job done 25-35% faster without any additional investment.

For gamers/miners:
Yeeah...!! Now you got a legit excuse to buy a decent graphic card and your second half can wait with the new outfit/bag/gym club card/whatever it is!

We'll keep on advancing and moving more functions to GPU. Have fun!

[Amarbir[CDR-Labs]]

Wow ,
Thats great news once you are recovering from your illness .Is there a way to enable/disable gpu support in VNR ,Not tried Ver 4.0 Update .Also GPU capability these days is far better the CPU ,In older years too the GPU cores way outnumber the CPU .Very nice addon .

[bos]

Maybe I'm doing something wrong in VNR 9.0, but when I use GPU-correction I see no increase in processing time at all. In the machine is an i7-13700 (16 cores, 24 logical) and an NVidia RTX 2060. Testing GPU-correction on a 16GB chip is just as slow as using the CPU-correction. Only difference is that the GPU-version reads a larger chunk of pages at once while the CPU-dito reads a smaller chunk. But speed-wise, both are the same, despite task manager showing "100% GPU usage" (instead of CPU).

On https://www.youtube.com/watch?v=a8ExeJ90Cac there is a comparison where they end up around 48 minutes for CPU-correction on 4GB. Extrapolating to 16GB it's 192 minutes, and that's about the speed / time I get when using either CPU/GPU for this case.

Is there an error log or similiar I can check, to find out why the GPU-correction is slow as a dino?

(screendump shows GPU-correction after about 90 minutes run)

Attachments

[Gregory]

GPU ECC came out 5 years ago, and Id like to know what the results are on current graphics cards - does anyone have such data? I personally only use CPU. I tried GPU once or twice, but it ended up damaging the dump. It would be great if someone could share their experience on this topic. Does anyone have the same issue as @bos? Thanks.

[melvin]

I always use GPU on first pass. The difference in speed is huge. Funny that it hardly rereads on first pass when i use reread dump with GPU. So it better works as correction. Next passes work ok with reread on GPU. If there are not so many pages to reread i use GPU.
Correcting/rereading Sandisk SSDs is something it shines. Now i can recover 4 chiped SSD within 2 days.

RYZEN 9 7950X + RTX3060.
Sadly GPU doesn't work on ECC based on bits.

[melvin]

If there are not so many pages to reread i use GPU.

I meant CPU.

[Gregory]

Thanks for share your expeirence, but "Huge" means what exactly? Similar to the example from VNR where there's an i7 7900K vs. RX5700, so about 5x? or RTX3060 is faster? I'm referring to the large ECC 230B (SanDisk).

[melvin]

I didn't compare how many X faster. You can get old while waiting VNR will correct 230B ECC dump on CPU. But with CPU i think i did Sandisk SSD within 7-10 days. I have a video from few years back where i said that doing it on Ryzen 7 will take about two weeks. Now it's doable in two. 4 BGA chips.

[ddrecovery]

I assume the Rusolut TS guys have data on the effectiveness of using the GPU for correction and the best GPU for the task? Guys?

[arvika]

Quite long time ago I make correction compare test on 32GB dump with layout 14_2048_230 on i7-8700K processor. Here is my notes:

FE: 3h50m
PC3K: 5h40m
VNR CPU: ~10h
VNR GPU: I was not able run it correcty on MSI GRT 1650, it hangs, not work etc, I give up.

But I remember that on some other cases I was able run GPU correcting and it was the fastest of course. But due to huge amount of problems with it, I generally not use GPU for this purpose.

I think the most important is programmer skill, which can optimize the code to work as fast as possible. No one thinks about it now.

[pepe]

programmer skill,

long time ago, far away in the eastern spiral arm of the galaxy... i wrote some code for DCT to analyze some sound samples. I wrote it in C, tested it and found it a bit slow, so i kindof manually compiled it to assembly with some optimization for pentium pipelining (yeah that was a new thing back then). It was run under DOS real mode, which means no 32bit instructions. The performance improvement was about tenfold. So yeah, programming skills greatly affect speed of programs, as well as their memory demand. (not as if i would call myself a skilled programmer).
A bit later i played with protected mode, switched my pentium manually to protmode and converted the code to use 32bit instructions. This resulted another 10% of performance gain (i expected more to be honest, but that was it.)
performance-critical loops should be written in asm i believe, but nobody (or very few) cares, just tell the user to buy better HW with more ram and faster cpus.
pepe

[Gregory]

No one thinks about it now.

I’m working on it, I have a working engine, and efforts are ongoing to handle bit offsets for ECC. Speed on a 7800x3D CPU: 4GB ECC230B sample takes about 48 seconds, 40GB takes 8 minutes, 400GB takes 80 minutes. This is on CPU, not GPU. For 120B ECC x2, e.g., 16GB takes 2 minutes.
ps. That’s why I was asking how it looks on your GPU, because I was curious if it makes sense to continue the project.