Experimental higher-fidelity C31 in 10.5 GB


#33

Getting a number of invalid share submissions (wasn’t getting any previously).


#34

Stale or rejected? The hashrate of the g31 improved.


#35

Rejected - on grinmint: ‘ERRO Failed to submit a solution: RpcError { code: -32502, message: “Failed to validate solution” }’


#36

If you want to restore the old behaviour, you can set -DNRB1=32 in CMakeLists.txt …


#37

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


#38

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.


What happened with C31 mining? the hashrate just went up 70% today?
Request for all miner devs
#39

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?


#40

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.


#41

Any body can share the binary please ?


#42

I’ve narrowed it down to one setting: genbtpb = 128. If I comment out that line, my system is stable. Otherwise, my whole machine reboots suddenly after a few minutes of running the miner (Ubuntu 18.04). This doesn’t seem hardware-related, but maybe I configured something incorrectly before compiling. I’ll let you know after the new binary is released.


#43

updated to the latest of @tromp 's memred2 repo, grin-miner reported 147 solutions found, the result from f2pool is still relatively lower.


#44

guys i am also having a crashing 2080ti since this morning an i do not know why
for a few days the miner ran normal but suddenly this morning i had this:


#45

sorry guys, i hate to be the dumbest guy in the room, but after compiling this, how do you run the miner? Is there a guide somewhere?

Help, please!


#46

well it’s just the binary, so ./grin-miner ?


#47

I complied the source code from https://github.com/tromp/cuckoo.git was that not correct, where is this binary you speak of?


#48

The source code was updated a few days ago, but there is no release binary yet.
Could Yeastplume update grin-miner binary as well please?


#49

@Yeastplume @tromp doubling the above. Update binaries, please.


#50

Hi. I’m mining on 2x 2080Ti and the miner was reporting 3.4gps before the changes. Now it says 2.5gps. Big drop and even if the fidelity is better, it’s not worth it. Why are some only seeing a few % drop?

I had set -DNRB1=26 -DNEPS_A=133 -DNEPS_B=85 in CMakeLists. If I try to push any higher than 133/85 it errors.

I’m using the Founder’s Edition 2080Ti’s which nvidia-smi reports as having 10989MB of total RAM. I’m running Ubuntu 18.04 with gnome/xorg disabled. 10930MB of ram is used when I run the miner with these new settings and 10975MB is used if I run with the old 32/128/80.

Thanks for any suggestions.


#51

With old settings, you got 3.4 * 0.7 (fidelity) = 2.38 real gps.
Now you get 2.5 real gps.
2.5 > 2.38. Not worth it?


#52

I was getting higher than 0.7 fidelity according to my pool. It was reading ~2.7gps, not 2.38gps, when my miner said 3.4gps. So I figured 2.7gps pool side is better than 2.5gps with 1.0 fidelity. Seems I’m getting greater than 1 fidelity somehow though with the changes cause I just checked my pool stats and it was reading ~3gps when my miner was saying only ~2.5…

Not sure how that’s possible but whatever, I guess I’ll be using the fix since that ultimately reads higher pool-side.