Any body can share the binary please ?
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.
updated to the latest of @tromp 's memred2 repo, grin-miner reported 147 solutions found, the result from f2pool is still relatively lower.
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:
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!
well it’s just the binary, so ./grin-miner ?
I complied the source code from https://github.com/tromp/cuckoo.git was that not correct, where is this binary you speak of?
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?
@Yeastplume @tromp doubling the above. Update binaries, please.
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.
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?
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.
After switching to the new version using my 2080 ti I started to see about 40% of shares to be invalid and rejected by the pools (both grinmint and grin-pool). Is that expected? I generally see much smaller number of accepted shares thus income after the switch.
I managed to run the miner for a few hours compiled with the -DNRB1=26 -DNEPS_A=133 -DNEPS_B=86 -DPART_BITS=0 -DEDGEBITS=31" options, but I’m going to try now the default -DNRB1=26 -DNEPS_A=133 -DNEPS_B=85 -DPART_BITS=0 -DEDGEBITS=31 to see if the number of rejected shares decreases.
If you are using f2pool - they always show higher hashrate than real, but make up for it via less rewards per their calculator. That way (by showing bigger hashrate) thay attract miners.
If you are using some other pool, then I don’t know what to say.
Graeme saw the following fragment in the grin-miner.log
Feb 01 13:41:29.050 DEBG Mining: Plugin 0 - Device 0 (GeForce RTX 2080 Ti) at Cuck(at)oo31 - Status: OK : Last Graph time: 0.566002158s; Graphs per second: 1.767 - Total Attempts: 579
Feb 01 13:41:29.050 INFO Mining: Cuck(at)oo at 1.7667777160665878 gps (graphs per second)
Feb 01 13:41:30.854 DEBG Client received message: FoundSolution(24159, 0, 31, 5009893231420838735, [669158, 17868415, 36075574, 100665665, 111270241, 172303331, 178092891, 240829710, 240829710, 240829710, 256558027, 390837081, 467482889, 548937752, 653815413, 742304104, 754690640, 834975780, 1055687027, 1170313120, 1312828255, 1371397031, 1508795379, 1510806775, 1510806775, 1510806775, 1521555783, 1524515468, 1530852255, 1546737683, 1546737683, 1546737683, 1720890187, 1754727164, 1833517118, 1867656916, 1916683657, 1951821832, 2041202105, 2059107819, 2073666422, 2116592049])
Feb 01 13:41:30.854 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"submit","params":{"edge_bits":31,"height":24159,"job_id":0,"nonce":5009893231420838735,"pow":[669158,17868415,36075574,100665665,111270241,172303331,178092891,240829710,240829710,240829710,256558027,390837081,467482889,548937752,653815413,742304104,754690640,834975780,1055687027,1170313120,1312828255,1371397031,1508795379,1510806775,1510806775,1510806775,1521555783,1524515468,1530852255,1546737683,1546737683,1546737683,1720890187,1754727164,1833517118,1867656916,1916683657,1951821832,2041202105,2059107819,2073666422,2116592049]}}
Feb 01 13:41:30.854 DEBG Client received message: FoundSolution(24159, 0, 31, 5009893231420838735, [669158, 17868415, 36075574, 100665665, 111270241, 172303331, 178092891, 240829710, 256558027, 390837081, 467482889, 548937752, 653815413, 742304104, 754690640, 834975780, 1055687027, 1170313120, 1312828255, 1371397031, 1508795379, 1510806775, 1510806775, 1510806775, 1510806775, 1521555783, 1524515468, 1530852255, 1546737683, 1546737683, 1546737683, 1546737683, 1720890187, 1754727164, 1833517118, 1867656916, 1916683657, 1951821832, 2041202105, 2059107819, 2073666422, 2116592049])
Feb 01 13:41:30.854 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"submit","params":{"edge_bits":31,"height":24159,"job_id":0,"nonce":5009893231420838735,"pow":[669158,17868415,36075574,100665665,111270241,172303331,178092891,240829710,256558027,390837081,467482889,548937752,653815413,742304104,754690640,834975780,1055687027,1170313120,1312828255,1371397031,1508795379,1510806775,1510806775,1510806775,1510806775,1521555783,1524515468,1530852255,1546737683,1546737683,1546737683,1546737683,1720890187,1754727164,1833517118,1867656916,1916683657,1951821832,2041202105,2059107819,2073666422,2116592049]}}
Feb 01 13:41:32.003 DEBG Received message: {"id":"0","jsonrpc":"2.0","method":"submit","result":null,"error":{"code":-32502,"message":"Failed to validate solution"}}
Feb 01 13:41:32.004 DEBG Received response with id: 0
Feb 01 13:41:32.004 ERRO Failed to submit a solution: RpcError { code: -32502, message: "Failed to validate solution" }
Feb 01 13:41:32.004 DEBG Received message: {"id":"0","jsonrpc":"2.0","method":"submit","result":null,"error":{"code":-32502,"message":"Failed to validate solution"}}
Feb 01 13:41:32.004 DEBG Received response with id: 0
Feb 01 13:41:32.004 ERRO Failed to submit a solution: RpcError { code: -32502, message: "Failed to validate solution" }
which shows the same solution with and without some indices replaced by duplicates of a previous index. This will take some time to debug…
1 Like
Finally figured out what was causing this. Had set the expand parameter in the plug-in definition section of the grin-miner.toml file to 2. (The default in the code is now 3). Changing this to 3 get’s rid of the invalid shares.
Yes, that’s what I pointed out in Experimental higher-fidelity C31 in 10.5 GB above …
I was messing with that just now:
Quadro P6000 with 24449MB @ 384 bits x 4513MHz
Looking for 42-cycle on cuckatoo31("",98-101) with 50% edges, 64*64 buckets, 176 trims, and 64 thread blocks.
Using 15616MB of global memory.
…
One question tho… is it possible to just change the NEPS_A/B for the OpenCL plugin? without having to re-write the code?