Quote from: jstefanop on Today at 05:54:32 PM

Quote from: Aldin1978 on Today at 01:33:19 PM

Quote from: MLOMBANA on October 31, 2021, 11:09:32 PM

With so many of us now using an Apollo for mining BTC and the fact that the box has its own node, has anyone taken the time to do a write up for us "slower" old guys that might want to take full advantage of the functions of the box as in use the node and the box together to solo mine?

Is it even possible to set up the Apollo BTC and Node to mine into itself in solo mode?

I'm mining to CKPool but wondering if I have the ability to use the Apollo to mine in my old world and not have to go to a pool.

A write-up or cheat sheet would be really welcome!

ml

I know this post is a couple months old, but in case the OP is still needing this (or others who might be looking to do the same), I was able to get my full-node unit mining my own node. I didn't do a 'write-up' of this, and it does require some basic / intermediate Linux knowledge, but in a nutshell:

I installed ckpool - source package found here (they don't supply pre-built binaries): (https://bitbucket.org/ckolivas/ckpool/get/b8f668524835.zip) and set up a simple pool in standalone mode (without ckdb support), with my local full node (127.0.0.1:8332) as the btcd, and 127.0.0.1:3333 as the address for miners to connect. Once I got bitcoin.conf (from the node) and ckpool.conf (from ckpool) set up so that everything was working as expected, I modified the script that starts up the node, to also start up the ckpool process.

Someone else may know a solution to this problem, but I had to replace the bitcoind binary with an earlier version 0.19.1 - this is because version 0.20.0 and later which removed the coinbaseaux flag from the GBT response, and ckpool doesn't play nice without it there (even though it isn't a required flag ...).

Then in the ApolloUI, I set up my pool as: stratum+tcp://127.0.0.1:3333 - User and pass: <same as rpcuser and rpcpassword from bitcoin.conf>.

Everything comes up on its own when I (re)start the device -- and if you don't change the RPC username / pass from the defaults, it also remains fully integrated with the UI, though obviously you don't see anything about ckpool (since the node_start script modification I made launches ckpool in a screen session (screen -dmS ckpool), like the node and miner services do, I can pull up the running ckpool output via (as root): screen -x ckpool). If you do change the rpcuser and rpcpassword from default, it breaks the UI - but at some point I'll probably take the time to figure out how to change the values the UI uses to connect so that I can change the RPC credentials.

Screenshots of results:

https://www.filehosting.org/file/details/976274/miner.jpg

https://www.filehosting.org/file/details/976275/node.jpg

@jstefanop : this unit has always had ~40% hardware errors since I first started it up 12/27, regardless which mining pool I used (tried ckpool, nicehash, slush, etc). The hashrate is as advertised, so I haven't been too worried about it - but is this a cause for concern?

Cool write up! We are testing a similar setup with ckpool codebase for our solo mining feature as well. RPC issue is on our to-do list as well. Once more services and apps are part of the system the RPC credentials will be tied to the user password that is set during setup.

HW error issue is not a concern, very small number of units will have this issue and its because 1 or 2 bad cores out of thousands of cores that are any our Apollo are constantly spitting back bad data. The way our system is designed its hard to filter out "real" HW errors due to low voltage/overheating on the cores from "bad" HW errors due to bad cores. As long as your rejected shares are not high, and the pool hashrate matches what you see in the dashboard your unit is operating fine.

Thanks! It seems very stable, got it going yesterday evening (not quite 24 hours yet), but looking good!

Lemme try those screenshots again:

https://i.postimg.cc/MK9KMsgP/miner.jpg

https://i.postimg.cc/rFVwp6ZR/node.jpg