# Experimental higher-fidelity C31 in 10.5 GB

**URL:** <https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211>\
**Category:** Mining\
**Created:** [January 25, 2019, 12:13pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211 "2019-01-25T12:13:59Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\
**Post date:** [January 25, 2019, 12:13pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/1 "2019-01-25T12:13:59Z")

</div>

In branch memred2 of my cuckoo repo, I now have seemingly working solvers cuda31.0 for RTX and cuda31.1 for GTX. See Makefile targets

cuda31.1: …/crypto/siphash.cuh mean.cu Makefile  
(NVCC) -o @ -DNRB1=26 -DNEPS\_A=133 -DNEPS\_B=85 -DPART\_BITS=1 -DEDGEBITS=31 -arch sm\_35 mean.cu $(BLAKE\_2B\_SRC)

cuda31.0: …/crypto/siphash.cuh mean.cu Makefile  
(NVCC) -o @ -DNRB1=26 -DNEPS\_A=133 -DNEPS\_B=85 -DPART\_BITS=0 -DEDGEBITS=31 -arch sm\_75 mean.cu $(BLAKE\_2B\_SRC)

The old solvers correspond to NRB1=32. This is the number of rows (out of 64) of bufferB that doesn’t overlap bufferA. By reducing it to 26, total memory size is reduced significantly, allowing NEPS\_A/B to be raised to more comfortable levels resulting in much higher fidelity. Since I’m travelling, I don’t have time to properly test these versions, but I’m making them available for people to experiment with.

Using these solvers in grin-miner would require going into  
grin-miner/cuckoo-miner/src/cuckoo\_sys/plugins/cuckoo/  
checking out branch memred2 and adjusting the compile options in CMakeLists.txt  
none of which I can test on my laptop…

---

<div class="post-metadata">

**Author:** ![g011um](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/g011um/32/745_2.png) [@g011um](https://forum.grin.mw/u/g011um)\
**Post date:** [January 25, 2019, 1:27pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/2 "2019-01-25T13:27:31Z")

</div>

Unfortunately, this doesn’t seem to work. On my RTX2080ti, cuda31.0 exits after 195ms (about the seeding time), and cuda31.1 does not find the 42-cycle for nonce 99, reports 2 28 10 10 10 10 10-cycle instead

---

<div class="post-metadata">

**Author:** ![zphou](https://avatars.discourse-cdn.com/v4/letter/z/54ee81/32.png) [@zphou](https://forum.grin.mw/u/zphou)\
**Post date:** [January 25, 2019, 3:19pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/3 "2019-01-25T15:19:06Z")

</div>

Have it built and running for about 2 mins, can’t tell difference atm.

---

<div class="post-metadata">

**Author:** ![fatchance](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/fatchance/32/953_2.png) [@fatchance](https://forum.grin.mw/u/fatchance)\
**Post date:** [January 26, 2019, 3:21am UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/4 "2019-01-26T03:21:06Z")

</div>

Also compiled and grin-miner is using the updated AT31 plugin with new compile flags.

> [@zphou](#):
>
> Have it built and running for about 2 mins, can’t tell difference atm.

Seems like it’s working as intended, in the sense that the grin-miner hashrate is less than the previous ~1.7 (now down to around ~1.5 range).

---

<div class="post-metadata">

**Author:** ![futurerheza](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@futurerheza](https://forum.grin.mw/u/futurerheza)\
**Post date:** [January 26, 2019, 5:48am UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/5 "2019-01-26T05:48:46Z")

</div>

Compiled also. I’m sure it has a lower rejected rate. Is there any thing we could do to get the number of fidelity ?

---

<div class="post-metadata">

**Author:** ![zphou](https://avatars.discourse-cdn.com/v4/letter/z/54ee81/32.png) [@zphou](https://forum.grin.mw/u/zphou)\
**Post date:** [January 26, 2019, 6:18am UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/6 "2019-01-26T06:18:21Z")

</div>

GPS on my rig is the same as before, the only difference I can tell is memred2 branch use up all the vRAM on each card, code from master branch uses about 50% of the vRAM

---

<div class="post-metadata">

**Author:** ![g011um](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/g011um/32/745_2.png) [@g011um](https://forum.grin.mw/u/g011um)\
**Post date:** [January 26, 2019, 6:29am UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/7 "2019-01-26T06:29:15Z")

</div>

Are you using the \_gtx or \_rtx plugin?  
Which version of CUDA are you using?

---

<div class="post-metadata">

**Author:** ![zphou](https://avatars.discourse-cdn.com/v4/letter/z/54ee81/32.png) [@zphou](https://forum.grin.mw/u/zphou)\
**Post date:** [January 26, 2019, 7:03am UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/8 "2019-01-26T07:03:24Z")

</div>

rtx pluging with latest cuda-10

---

<div class="post-metadata">

**Author:** ![lofino](https://avatars.discourse-cdn.com/v4/letter/l/d26b3c/32.png) [@lofino](https://forum.grin.mw/u/lofino)\
**Post date:** [January 28, 2019, 1:51am UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/9 "2019-01-28T01:51:15Z")

</div>

> [@tromp](#):
>
> CMakeLists.txt

Mmm what has to be changed in the CMakeLists.txt file ?

---

<div class="post-metadata">

**Author:** ![fatchance](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/fatchance/32/953_2.png) [@fatchance](https://forum.grin.mw/u/fatchance)\
**Post date:** [January 28, 2019, 4:36am UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/10 "2019-01-28T04:36:06Z")

</div>

> [@tromp](#):
>
> CMake

You have to add the new compile flags that @tromp mentioned above to the CMakeLists.txt file, more specifically in the `if (NOT SKIP_CUCKATOO_GPU)` section.

---

<div class="post-metadata">

**Author:** ![cuckoo](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/cuckoo/32/845_2.png) [@cuckoo](https://forum.grin.mw/u/cuckoo)\
**Post date:** [January 28, 2019, 6:33am UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/11 "2019-01-28T06:33:04Z")

</div>

build failed with `'CMakeFiles/cuckatoo_mean_cuda_rtx_31.dir/all' failed` when I update CMakeList.txt with the additional flags as shown below.

`build_cuda_target("${AT_MEAN_CUDA_SRC}" cuckatoo_mean_cuda_rtx_31"-DNRB1=26 -DNEPS_A=133 -DNEPS_B=85 -DPART_BITS=0 -DEDGEBITS=31")`

---

<div class="post-metadata">

**Author:** ![fatchance](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/fatchance/32/953_2.png) [@fatchance](https://forum.grin.mw/u/fatchance)\
**Post date:** [January 28, 2019, 8:01am UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/12 "2019-01-28T08:01:29Z")

</div>

As @tromp said up above:

> [@tromp](#):
>
> In branch memred2 of my cuckoo repo […]

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).

> [@cuckoo](#):
>
> build failed with `'CMakeFiles/cuckatoo_mean_cuda_rtx_31.dir/all' failed` when I update CMakeList.txt with the additional flags as shown below.

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.

---

<div class="post-metadata">

**Author:** ![colincr33vey](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/colincr33vey/32/611_2.png) [@colincr33vey](https://forum.grin.mw/u/colincr33vey)\
**Post date:** [January 28, 2019, 7:58pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/13 "2019-01-28T19:58:41Z")

</div>

```
grin-miner/cuckoo-miner/src/cuckoo_sys/plugins/cuckoo/src/cuckatoo/mean.cu(618): error: no instance of function template "Round2" matches the argument list

argument types are: (int, u32, siphash_keys, u32 *, uint2 *, u32 *, u32 *)

```

Latest memred2 branch pulled, CMakeList updated to the same as cuckoo’s ^

---

<div class="post-metadata">

**Author:** ![Levicorpus](https://avatars.discourse-cdn.com/v4/letter/l/73ab20/32.png) [@Levicorpus](https://forum.grin.mw/u/Levicorpus)\
**Post date:** [January 28, 2019, 8:18pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/14 "2019-01-28T20:18:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![fatchance](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/fatchance/32/953_2.png) [@fatchance](https://forum.grin.mw/u/fatchance)\
**Post date:** [January 28, 2019, 8:52pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/15 "2019-01-28T20:52:35Z")

</div>

> [@colincr33vey](#):
>
> Latest memred2 branch pulled, CMakeList updated to the same as cuckoo’s ^

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.

---

<div class="post-metadata">

**Author:** ![colincr33vey](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/colincr33vey/32/611_2.png) [@colincr33vey](https://forum.grin.mw/u/colincr33vey)\
**Post date:** [January 28, 2019, 9:09pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/16 "2019-01-28T21:09:05Z")

</div>

Ah, glad to hear I’m not alone – I was thinking it was user error on my behalf. Yeah, no harm in waiting, thanks for the reply

---

<div class="post-metadata">

**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\
**Post date:** [January 29, 2019, 8:14pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/17 "2019-01-29T20:14:16Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![hans1024](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/hans1024/32/1128_2.png) [@hans1024](https://forum.grin.mw/u/hans1024)\
**Post date:** [January 29, 2019, 8:41pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/18 "2019-01-29T20:41:45Z")

</div>

How can I best test the fidelity?  
Like this:  
./cuda31.0 -d 0 -r 1000 | perl …/perl/cycles.pl  
and report the outputs?

---

<div class="post-metadata">

**Author:** ![graemes](https://avatars.discourse-cdn.com/v4/letter/g/cc9497/32.png) [@graemes](https://forum.grin.mw/u/graemes)\
**Post date:** [January 29, 2019, 9:43pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/19 "2019-01-29T21:43:59Z")

</div>

2080ti:  
./cuda31.0 -d 0 -r 1000 | perl …/perl/cycles.pl  
42 24 1.008

---

<div class="post-metadata">

**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\
**Post date:** [January 29, 2019, 10:08pm UTC](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211/20 "2019-01-29T22:08:14Z")

</div>

yes, the larger the range the better.

btw, one can try to further improve fidelity by increasing NEPS\_A/B until running out of memory…

[Next page](https://forum.grin.mw/t/experimental-higher-fidelity-c31-in-10-5-gb/3211.md?page=2)
