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

WBF1

sr. member

Activity: 419

Merit: 250

Quote from: igorwhite on February 25, 2016, 08:40:35 AM

Hello!
I get this error when doing blocknotify.

Quote

~$ Failed to bind to socket in open_unix_client
Closing file handle 5
Failure in open_unix_client from notifier.c main:50
Failed to open socket: /tmp/ckpool/stratifier

What could be the problem?

Make sure /tmp/ckpool/stratifier exists. It's a socket opened by ckpool. Probably also need to make sure the user running bitcoind has access to that socket. This may not be the case especially if bitcoind is running as a service but you're running ckpool from command line.

igorwhite

member

Activity: 114

Merit: 10

Hello!
I get this error when doing blocknotify.

Quote

~$ Failed to bind to socket in open_unix_client
Closing file handle 5
Failure in open_unix_client from notifier.c main:50
Failed to open socket: /tmp/ckpool/stratifier

What could be the problem?

WBF1

sr. member

Activity: 419

Merit: 250

Cool yeah I built master just now and no problems so far

chiguireitor

legendary

Activity: 872

Merit: 1010

Coins, Games & Miners

Can confirm master is stable as a rock.

WBF1

sr. member

Activity: 419

Merit: 250

Quote from: -ck on February 24, 2016, 05:48:48 PM

Quote from: WBF1 on February 24, 2016, 05:02:58 PM

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

great so use M tags for stability when in doubt

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: WBF1 on February 24, 2016, 05:02:58 PM

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

WBF1

sr. member

Activity: 419

Merit: 250

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

WBF1

sr. member

Activity: 419

Merit: 250

Quote from: -ck on February 24, 2016, 03:45:36 PM

Quote from: WBF1 on February 24, 2016, 05:50:37 AM

Quote from: -ck on February 14, 2016, 08:01:25 AM

Quote from: WBF1 on February 14, 2016, 07:53:47 AM

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: WBF1 on February 24, 2016, 05:50:37 AM

Quote from: -ck on February 14, 2016, 08:01:25 AM

Quote from: WBF1 on February 14, 2016, 07:53:47 AM

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

sr. member

Activity: 419

Merit: 250

Quote from: -ck on February 14, 2016, 08:01:25 AM

Quote from: WBF1 on February 14, 2016, 07:53:47 AM

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.

ksoze75

newbie

Activity: 5

Merit: 0

Unsupported Sad

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

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

irritant

sr. member

Activity: 473

Merit: 250

Sodium hypochlorite, acetone, ethanol

Quote from: ksoze75 on February 24, 2016, 01:12:53 AM

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?

Quote from: -ck on September 20, 2014, 08:23:41 PM

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

newbie

Activity: 5

Merit: 0

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

WBF1

sr. member

Activity: 419

Merit: 250

Thanks for the quick replies.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: WBF1 on February 17, 2016, 10:19:11 PM

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

sr. member

Activity: 419

Merit: 250

Quote from: -ck on February 17, 2016, 10:10:04 PM

Quote from: WBF1 on February 17, 2016, 10:08:35 PM

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: WBF1 on February 17, 2016, 10:08:35 PM

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

sr. member

Activity: 419

Merit: 250

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: WBF1 on February 17, 2016, 10:00:29 PM

@ -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

sr. member

Activity: 419

Merit: 250

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

Topic: CKPOOL - Open source pool/proxy/passthrough/redirector/library in c for Linux - page 11. (Read 124144 times)