This means you need to merge the changes that @tromp made to his memred2 cuckoo repository on GitHub, make sure it compiles properly on your server, update the specific files that were revised, update CMakeLists.txt, and then re-compile (and solve any compilation errors on the way).
Modifying the CMakeLists.txt file is the second-to-last step in the process. If you didn’t do the first few critical steps then it’s better to wait until they’re packaged up.
Is there a quick way to tell whether you did it right? I’m running both versions now on different GPU. The experimental version seems to get a few more solutions, so far 21 vs 28, could still be luck though.
I just ran into the same issue. I think that @tromp’s latest commits broke the compilation process. Perhaps go back a few commits before he went to GrinConUS. From what I’m understanding, the improvements he made weren’t performance related at all, but more around reporting so that the reported gps rates in grin-miner match the gps rates that mining pools are reporting.
Ultimately, I think we’re going to have to wait for him to come back before we see further commits for both C31 and (hopefully) C32.
Ok, think I have most if not all bugs fixed now.
Please try latest memred2 commit, and let me know if you still see problems, or if it works for you. Even better if you can give fidelity stats…
NOTE: there is now an option to set expand to 3,
which is the default for 30+
This means that when trying the new solver within grin-miner, you need to avoid setting expand=2
yes, of course.
cuda31.0 and cuda31.1 only differ in PART_BITS setting, which has no effect on DRAM use, or on fidelity…
PART_BITS=0 is just a little faster, but requires 64 KB shared memory, only available on RTX…
That seemed to work but seem to be getting a number of invalid shares on grinmint: ‘ERRO Failed to submit a solution: RpcError { code: -32502, message: “Failed to validate solution” }’. Poolside hash rate seems to be the same as before.
This will be great for 1080tis that use xorg for OC. Appreciate the efforts on this & looking forward to release.
Curious how one would decrease mem reqs further like minerbabe did with C31 on 8g. Is it lowering NRB1 with poorer fidelity? Adjusting expand for less mem & slower solve time?
2080 ti here. I seem to be getting a lot more rejected shares – about 150 accepted / 75 rejected in the past 8 hours. I’ll rebuild run again and report back.
Update: Getting significantly more rejected shares w/ -DNRB1=26 -DNEPS_A=133 -DNEPS_B=85 -DPART_BITS=0 -DEDGEBITS=31
and latest memred2 branch. I seem to be an outlier here so maybe it’s me.
Update 2: I hadn’t changed expand=3 in grin-miner.toml