CKPOOL - Open source pool/proxy/passthrough/redirector/library in c for Linux

[Subw]

yes looks like only MRR doing this, tried stratum.f2pool.com and it is fine too

[1714923036]

1714923036

[1714923036]

1714923036

[1714923036]

1714923036

[1714923036]

1714923036

[WBF1]

Hi ck

I'm getting the same errors over and over. I cloned and built from commit db42a13. Built with all dependencies satisfied. No build problems that I can remember. Running from build directory, not installed. Environment is 32-bit Arch Linux Arm running on a Raspberry Pi2. I haven't yet taken a dive into the lines of code specified here. Was hoping maybe this is something you've encountered before with an easy fix. Any help/pointers would be much appreciated.

Looks to me like stratifier and generator are not starting. I checked and all the sockets and such are getting successfully created in /tmp/ckpool. bitcoind is slow in responding sometimes on this box. Not sure if that could cause this issue.

command line:

Code:

./ckpool -k -A -c ../ckproxy2.conf

ckproxy2.conf:

Code:

{
"btcd" :  [
        {
                "url" : "localhost:8332",
                "auth" : "[user]",
                "pass" : "[pass]"
        }
],
"update_interval" : 30,
"serverurl" : [
        "127.0.0.1:3334"
        ],
"mindiff" : 1,
"startdiff" : 1000,
"maxdiff" : 0,
"logdir" : "logs",
"btcaddress" : "[address]",
"btcsig" : "[sig]"
}

console output:

Code:

[2016-02-14 07:35:22.481] ckpool stratifier starting
[2016-02-14 07:35:22.481] ckpool generator starting
[2016-02-14 07:35:22.482] ckpool connector starting
[2016-02-14 07:35:22.483] ckpool connector ready
[2016-02-14 07:35:27.484] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory
[2016-02-14 07:35:27.485] Failure in recv_unix_msg from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:27.485] Failure in send_recv_proc from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:32.487] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory
[2016-02-14 07:35:32.488] Failure in recv_unix_msg from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:32.488] Failure in send_recv_proc from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:37.490] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory

log output:

Code:

[2016-02-14 07:35:22.475] Setting maxclients to 921 due to max open file limit of 1024
[2016-02-14 07:35:22.481] ckpool stratifier starting
[2016-02-14 07:35:22.475] Setting maxclients to 921 due to max open file limit of 1024
[2016-02-14 07:35:22.481] ckpool generator starting
[2016-02-14 07:35:22.482] ckpool connector starting
[2016-02-14 07:35:22.483] ckpool connector ready
[2016-02-14 07:35:27.484] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory
[2016-02-14 07:35:27.485] Failure in recv_unix_msg from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:27.485] Failure in send_recv_proc from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:32.487] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory
[2016-02-14 07:35:32.488] Failure in recv_unix_msg from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:32.488] Failure in send_recv_proc from stratifier.c stratifier:7546 with errno 2: No such file or directory

[-ck]

Environment is 32-bit ...

Ckpool demands a 64 bit environment and I have no interest in creating support for 32 bits sorry.

[WBF1]

Environment is 32-bit ...

Ckpool demands a 64 bit environment and I have no interest in creating support for 32 bits sorry.

Interesting. Thanks for clearing that up.

[WBF1]

Interestingly, it may actually have been working fine. I got similar errors on 64-bit as well. Issue seemed to be hangups with bitcoind. Adding more RAM and setting bitcoind to properly use the notifier seems to made it all work a lot smoother. Still running it on 64-bit.

[WBF1]

@ -ck

Can you elaborate from a high level what exactly happens when ckpool is notified by the notifier? I can see that it seems like miners start in on a new block immediately. How does ckpool decide which transactions to put in that new block? (I ask because it seems like miners start on the new block before the last one is fully downloaded and verified... But I could be mistaken on that).  I'm guessing since all we really need is the hash of the previous block we can start with that before its fully verified? Or am I really wrong in thinking that we are working on the next block before the last one is fully verified?

I see this on the first post:

"New work generation on block changes incorporate full bitcoind transaction
set without delay"

But from experience, I don't see the delay surrounding block changes that seemed to be present when mining directly to a node via GBT, so just a little curious how this works.

And yeah I know I can probably figure this all out by diving into the code, but I don't read code very well and was hoping a high level explanation wouldn't be too much of an ask.

[-ck]

@ -ck

Can you elaborate from a high level what exactly happens when ckpool is notified by the notifier? I can see that it seems like miners start in on a new block immediately. How does ckpool decide which transactions to put in that new block? (I ask because it seems like miners start on the new block before the last one is fully downloaded and verified... But I could be mistaken on that).  I'm guessing since all we really need is the hash of the previous block we can start with that before its fully verified? Or am I really wrong in thinking that we are working on the next block before the last one is fully verified?

I see this on the first post:

"New work generation on block changes incorporate full bitcoind transaction
set without delay"

But from experience, I don't see the delay surrounding block changes that seemed to be present when mining directly to a node via GBT, so just a little curious how this works.

And yeah I know I can probably figure this all out by diving into the code, but I don't read code very well and was hoping a high level explanation wouldn't be too much of an ask.

The notify comes from bitcoind only once it has verified the previous block, the notifier then tells ckpool that bitcoind is ready to generate a new template so ckpool immediately requests a new template and works from that. It is always a fully verified block that ckpool works with and the getblocktemplate that bitcoind generates after the verified block.

[WBF1]

Ah okay I wasn't sure when the block notify was triggered by bitcoind. Thanks for that info.

I have a follow up, seemingly basic question that I couldn't find an answer to elsewhere... Do all miners everywhere concurrently work on the same block with the same transactions in it, or are the contents of a block at the discretion of each miner (assuming there are more than enough transactions on the mempool to cover more than one block worth)?

Sorry for getting a bit off topic...

[-ck]

Ah okay I wasn't sure when the block notify was triggered by bitcoind. Thanks for that info.

I have a follow up, seemingly basic question that I couldn't find an answer to elsewhere... Do all miners everywhere concurrently work on the same block with the same transactions in it, or are the contents of a block at the discretion of each miner (assuming there are more than enough transactions on the mempool to cover more than one block worth)?

Sorry for getting a bit off topic...

Same workinfo, same transactions for everyone.

[WBF1]

Ah okay I wasn't sure when the block notify was triggered by bitcoind. Thanks for that info.

I have a follow up, seemingly basic question that I couldn't find an answer to elsewhere... Do all miners everywhere concurrently work on the same block with the same transactions in it, or are the contents of a block at the discretion of each miner (assuming there are more than enough transactions on the mempool to cover more than one block worth)?

Sorry for getting a bit off topic...

Same workinfo, same transactions for everyone.

So I think I phrased that wrong or confusingly. By miners I didn't mean miners on the same pool. I meant I guess pools as mining entities, or maybe more accurately mining nodes. Wouldn't each node or pool potentially include a different transaction set per the block they are working on? Sorry these are probably really basic questions I can answer by re-reading the white paper or some other source.

I do have a more ckpool-specific question... Before I had the notifier and blocknotify setup on my bitcoind, there were times my miners were working on work that appears to be from previous blocks. It also seemed that ckpool would timeout when trying to get work from bitcoind. None of this happens anymore.

Is that because the "blockpoll" method is taxing on bitcoind? Or is it because requesting a new blocktemplate during verification causes slowdowns? Or both?

[-ck]

I do have a more ckpool-specific question... Before I had the notifier and blocknotify setup on my bitcoind, there were times my miners were working on work that appears to be from previous blocks. It also seemed that ckpool would timeout when trying to get work from bitcoind. None of this happens anymore.

Is that because the "blockpoll" method is taxing on bitcoind? Or is it because requesting a new blocktemplate during verification causes slowdowns? Or both?

Both

[WBF1]

Thanks for the quick replies.

[ksoze75]

I am trying to get this compiled and running on my RPi2B with Jessie lite. I git cloned the source and attempted to run autogen.sh and got the following output:

autom4te: cannot create autom4te.cache: No such file or directory
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

I am guessing I am doing something wrong here. I am fairly new to Linux and am learning as fast as I can but I have no idea where to go with this other than check out the script and see what it is looking for and it is indeed missing.

Any help for this noob would be great.

K

[irritant]

I am trying to get this compiled and running on my RPi2B with Jessie lite. I git cloned the source and attempted to run autogen.sh and got the following output:

autom4te: cannot create autom4te.cache: No such file or directory
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

I am guessing I am doing something wrong here. I am fairly new to Linux and am learning as fast as I can but I have no idea where to go with this other than check out the script and see what it is looking for and it is indeed missing.

Any help for this noob would be great.

K

have you installed autoconf and automake?

Building from git also requires autoconf and automake

sudo apt-get install build-essential libpq-dev autoconf automake libtool
./autogen.sh
./configure
make

dont know if it works on 32 bit but i read there is no support for it (rpi2b)

[ksoze75]

Unsupported . I thought RPi2B was 64 bit. Maybe not, oh well.

I am pretty sure I installed those pkgs, I'll double check.

[WBF1]

Environment is 32-bit ...

Ckpool demands a 64 bit environment and I have no interest in creating support for 32 bits sorry.

But I was able to build and run on RPi2. I got errors while it was running but they may not have been related to running in a 32 bit environment.

Note that you'll definitely not be able to run with ckdb, as I believe it's recommended to have 16 GB ram or so for a full ckdb implementation running behind ckpool.

[-ck]

Environment is 32-bit ...

Ckpool demands a 64 bit environment and I have no interest in creating support for 32 bits sorry.

But I was able to build and run on RPi2. I got errors while it was running but they may not have been related to running in a 32 bit environment.

Note that you'll definitely not be able to run with ckdb, as I believe it's recommended to have 16 GB ram or so for a full ckdb implementation running behind ckpool.

Warnings at startup are not actually unusual or fatal as the multiprocess nature of ckpool means that sometimes one process waits excessively for another process - usually because they're waiting on bitcoind responses for example. The latest git version has moved away from the multiprocess model so those warnings shouldn't occur any more. While the code was made to be general and should work on 32 bit and big endian, the fact remains that it was never tested on either of those so they should be considered unsupported. Of course if someone wants to audit the code and test it on those platforms and contribute patches to fix any issues they find, they're welcome to. Unlike cgminer, though, for speed of development the code for ckpool was intentionally designed with one platform in mind - making code suit multiple architectures and operating systems means dealing with the quirks of low level behaviour of each platform which slows development down and often limits what can even be done with the code. Since ckpool uses low level socket code and system functions all over the place, cross-platform support, for example, is never going to happen.

[WBF1]

Environment is 32-bit ...

Ckpool demands a 64 bit environment and I have no interest in creating support for 32 bits sorry.

But I was able to build and run on RPi2. I got errors while it was running but they may not have been related to running in a 32 bit environment.

Note that you'll definitely not be able to run with ckdb, as I believe it's recommended to have 16 GB ram or so for a full ckdb implementation running behind ckpool.

Warnings at startup are not actually unusual or fatal as the multiprocess nature of ckpool means that sometimes one process waits excessively for another process - usually because they're waiting on bitcoind responses for example. The latest git version has moved away from the multiprocess model so those warnings shouldn't occur any more. While the code was made to be general and should work on 32 bit and big endian, the fact remains that it was never tested on either of those so they should be considered unsupported. Of course if someone wants to audit the code and test it on those platforms and contribute patches to fix any issues they find, they're welcome to. Unlike cgminer, though, for speed of development the code for ckpool was intentionally designed with one platform in mind - making code suit multiple architectures and operating systems means dealing with the quirks of low level behaviour of each platform which slows development down and often limits what can even be done with the code. Since ckpool uses low level socket code and system functions all over the place, cross-platform support, for example, is never going to happen.

Yup. I'll be testing on 64 bit ARM as soo as my Odroid C2 comes in.

[WBF1]

@ck are the M* tags considered more stable than master? or S* tags? are there still version numbers for stable releases?

[-ck]

@ck are the M* tags considered more stable than master? or S* tags? are there still version numbers for stable releases?

Tagged versions are considered stable for use indeed. The S tags were a mistake, the M tags stand for "milestone" releases. Having said that, the current git master is currently stable but that can change at any time. The version numbers are almost an afterthought.