Very promising!
Will merge into master tomorrow, and ask Yeastplume to update grin-miner, if no issues come up…
1080ti:
./cuda31.1 -d 1 -r 1000 | perl …/perl/cycles.pl
42 24 1.008
Identical?
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…
Having a brain freeze - can someone please tell me the command to update the submodule in grin-miner to use the memred2 branch.
Maybe just copy the memred2 version of cuckatoo/mean.cu over,
and update the compilation in CMakeLists.txt …
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?
With a rtx2080ti I also got 42 24 1.008
before I had about 1.6 gps, now 1.5 but grinmint seems to accept almost all shares reported by the miner
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
Can anyone share the binary please. 
1080ti:
ran the ./cuda31.1 -d 0 -r 1000 | perl …/perl/cycles.pl from the memred2 branch and added the new mean.cu to the build. Worked so far with a 2% improvement
Here is the output of the terminal:
2 499 0.998
4 229 0.916
6 161 0.966
8 131 1.048
10 99 0.99
12 101 1.212
14 78 1.092
16 57 0.912
18 55 0.99
20 54 1.08
22 43 0.946
24 32 0.768
26 38 0.988
28 43 1.204
30 35 1.05
32 24 0.768
34 35 1.19
36 26 0.936
38 19 0.722
40 17 0.68
42 24 1.008
1000 nonces 7 cycles at nonce 276
Assuming this confirms your information
I’ve pushed the changes into my master branch. So instead of copying over mean.cu you can now use something like
cuckoo-miner/src/cuckoo_sys/plugins
git submodule update --recursive --remote --merge
vi CMakeLists.txt
to update mean.cu and edit the -DNRB1=26 -DNEPS_A=133 -DNEPS_B=85 settings,
alternately incrementing NEPS_B and NEPS_A until you almost run out of memory, to maximize fidelity. I think it should be over 0.999 when you get to -DNEPS_A=135 -DNEPS_B=88
Getting a number of invalid share submissions (wasn’t getting any previously).
Stale or rejected? The hashrate of the g31 improved.
Rejected - on grinmint: ‘ERRO Failed to submit a solution: RpcError { code: -32502, message: “Failed to validate solution” }’
If you want to restore the old behaviour, you can set -DNRB1=32 in CMakeLists.txt …
Created some additional cuda31.X builds and tested different configurations. So far, can’t see significant improvements. NAPS_A = 133,134,135 and NAPS_B = 85,86,87,88,89,90 tested on a 1080ti
A run of 42000 nonces produced
2 21229 1.01090476190476
4 10409 0.991333333333333
6 7012 1.00171428571429
8 5290 1.00761904761905
10 4258 1.01380952380952
12 3582 1.02342857142857
14 3000 1
16 2661 1.01371428571429
18 2363 1.01271428571429
20 2161 1.02904761904762
22 1874 0.981619047619048
24 1766 1.00914285714286
26 1554 0.962
28 1477 0.984666666666667
30 1371 0.979285714285714
32 1248 0.950857142857143
34 1253 1.01433333333333
36 1189 1.01914285714286
38 1137 1.02871428571429
40 1021 0.972380952380952
42 943 0.943
Although the count of 42-cycles only suggests a fidelity of 94.3 %, a more reliable fidelity can be obtained by averaging over say all 10 cycle lengths between 24 and 42 which gives close to 99%.
The solver is a few % slower than before but the increased fidelity form around 70% to around 99% should more than make up for that.
This is causing some of my 2080 Tis to crash when mining with the default RTX parameters in grin-miner.toml, even after changing expand to 3. After a few minutes of mining, nvidia-smi reports that a “GPU is lost” and I have to reboot. Commenting everything out except device number and cpuload restores stability.
Are the default miner plugin settings (ntrims, genablocks, trimtpb, etc) no longer appropriate?
No idea why your “GPU is lost”; I mined for over 7 hours on a 2080Ti generously provided by Graeme Seaton without any issue.
Those are all still appropriate.