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

[-ck]

Hello.
The maximum number of miners can be connected to a ckproxy?

Unlimited.

[1715199680]

1715199680

[1715199680]

1715199680

[bitmine49]

What is the best way to move from a standalone ckpool to proxy/stratum - is it just rerunning ckpool -P

[WBF1]

@ck I'm running on commit f35f54a (https://bitbucket.org/ckolivas/ckpool/commits/f35f54a6428a99bacad6daedbd7cd8367c985242) from 2/23/16. I recently started noticing the odd occasion where there is a 2-40 second lag between block change of bitcoind/notifier running and ckpool logging a "block hash changed" message.

When I was running this on a different box with half as many cores and same amt of RAM, I was getting no lag at all (seeing less than a second between "UpdateTip" from bitcoind to "block hash changed" from ckpool).

One difference in the two boxes is file system. Could suboptimal fs performance be causing this? The older, seemingly quicker-to-change setup had the blockchain stored on ext4 while the newer, seemingly laggier-to-change setup has the blockchain stored on btrfs (I wanted to save some physical space with transparent compression... note to all: feel free to berate me on use of btrfs, but I don't want to derail this thread).

I can obviously reformat to ext4 and copy the blockchain over and back from a backup volume, but before I go through all that headache, I wanted to get your perspective on if it could be the root cause of the lagginess.

[-ck]

Doubt it. That lag time sounds like it missed a notify entirely.

[WBF1]

I dug a little deeper and it seems it coordinates with warnings from ckdb about taking a long time to getblocktemplate, which I guess is not surprising. I guess bitcoind is running slow or something. whther or not that could be affected so much by filesystem I know is off topic here, but an interesting thing to inspect I guess.

[-ck]

I dug a little deeper and it seems it coordinates with warnings from ckdb about taking a long time to getblocktemplate, which I guess is not surprising. I guess bitcoind is running slow or something. whther or not that could be affected so much by filesystem I know is off topic here, but an interesting thing to inspect I guess.

Tuning/hacking/optimising bitcoind is a whole topic in and of itself and it can perform terribly bad. That's why solo/kano.is run our own custom modified coin daemons (no there is no public code for these). Plus you're running classic as far as I can tell and that carries with it whatever separate differences it has itself. All of which are offtopic for this thread.

[WBF1]

Agreed on all counts. Thanks for the input though.

[WBF1]

Oh I guess unrelated question: any reason not to run on the latest version in the master tree? Is that what you're typically using in production? I know I've asked about the M tags before, but it doesn't seem like they keep up as much, as there hasn't been one in over a month (which isn't a big deal, but just curious).

[-ck]

Oh I guess unrelated question: any reason not to run on the latest version in the master tree? Is that what you're typically using in production? I know I've asked about the M tags before, but it doesn't seem like they keep up as much, as there hasn't been one in over a month (which isn't a big deal, but just curious).

There was very real instability in there. New tag just hit.

[WBF1]

Oh I guess unrelated question: any reason not to run on the latest version in the master tree? Is that what you're typically using in production? I know I've asked about the M tags before, but it doesn't seem like they keep up as much, as there hasn't been one in over a month (which isn't a big deal, but just curious).

There was very real instability in there. New tag just hit.

recommend M24 then or v0.9.3?

[kano]

Oh I guess unrelated question: any reason not to run on the latest version in the master tree? Is that what you're typically using in production? I know I've asked about the M tags before, but it doesn't seem like they keep up as much, as there hasn't been one in over a month (which isn't a big deal, but just curious).

There was very real instability in there. New tag just hit.

recommend M24 then or v0.9.3?

He said M tags before for a reason ...

[chiguireitor]

Do you by any chance have a consolidated log of the changes since last tag? (don't asking you to do it, just to see if there's a convenient place already to not waste time).

[WBF1]

Do you by any chance have a consolidated log of the changes since last tag? (don't asking you to do it, just to see if there's a convenient place already to not waste time).

Read the titles of each commit on bitbucket.  Ck and kano seem to provide very descriptive info in the titles of the commits.

[chiguireitor]

...

Read the titles of each commit on bitbucket.  Ck and kano seem to provide very descriptive info in the titles of the commits.

Yeah, i have the repo cloned, you can get a log since some commits ago, but i wanted to know if there was no necessity of doing that.

[zOU]

Hello

I have 8 miners and I'm in the process of getting them hosted in a plce with low power cost.

It would greatly help me to have only 1 IP address accessing internet/kano.is.

So I was wondering if I could use CK proxy to do the following:

Miners ->ethernet switch-> RPI -> wireless -> internet router

This way I could have a separate LAN for my miners and install ckpool/proxy (and cryptoglance) on the RPI.

Before I try to make it work at home (miners are currently directly connected behind a firewall) i'd like to know if it would work ?

Thank you

[kano]

One problem is that you'd be trusting all your hash rate to an RPi
However, we don't compile/test/run ckpool/ckdb ever on a 32bit environment ... and never will.

Simplest to get a small PC and put ubuntu on it and then run ckproxy on that.
Ubuntu says how to install it on any PC, and ckpool says how to compile and run it as a proxy in the README

[zOU]

Thank you Kano.

Maybe I'm trying too hard, using the RPI as as network gateway would be simply enough probably or an ethernet to Wi-Fi bridge...

[irritant]

rpi3 is 64bit iirc

edit: ok im half wrong, it needs more time
memory would probably be on the low side anyway

The Raspberry Pi 3 may have 64-bit CPU, but for now its default Linux OS remains at 32 bits.

The arrival of the $35, wireless-enabled, Raspberry Pi 3, following a similarly 64-bit, $40 Odroid-C2 SBC a few weeks ago, represent a big speed boost for Linux hacker boards but not a sudden switch to 64-bit ARM computing. While the Odroid project offers an Ubuntu 64-bit image for the C2, the default Linux distribution released by the Raspberry Pi Foundation is still 32-bit.

An eventual change to 64-bit ARM firmware is inevitable given the fact that the technology offers significantly improved performance. Pressure will also come from more power-efficient, 64-bit x86 chips. Yet, because of the extensive reworking of code required for the changeover, the Raspberry Pi Foundation will commit only to “considering” a change to 64-bit for the Pi’s default Raspbian distribution in the coming months.

[klintay]

rpi3 is 64bit iirc

edit: ok im half wrong, it needs more time
memory would probably be on the low side anyway

The Raspberry Pi 3 may have 64-bit CPU, but for now its default Linux OS remains at 32 bits.

The arrival of the $35, wireless-enabled, Raspberry Pi 3, following a similarly 64-bit, $40 Odroid-C2 SBC a few weeks ago, represent a big speed boost for Linux hacker boards but not a sudden switch to 64-bit ARM computing. While the Odroid project offers an Ubuntu 64-bit image for the C2, the default Linux distribution released by the Raspberry Pi Foundation is still 32-bit.

An eventual change to 64-bit ARM firmware is inevitable given the fact that the technology offers significantly improved performance. Pressure will also come from more power-efficient, 64-bit x86 chips. Yet, because of the extensive reworking of code required for the changeover, the Raspberry Pi Foundation will commit only to “considering” a change to 64-bit for the Pi’s default Raspbian distribution in the coming months.

Yes Raspberry Pi 3 is definitely 64 bit, they are available for sale right now here:
https://bitcointalk.org/index.php?topic=1419675

[-ck]

rpi3 is 64bit iirc

edit: ok im half wrong, it needs more time
memory would probably be on the low side anyway

The Raspberry Pi 3 may have 64-bit CPU, but for now its default Linux OS remains at 32 bits.

The arrival of the $35, wireless-enabled, Raspberry Pi 3, following a similarly 64-bit, $40 Odroid-C2 SBC a few weeks ago, represent a big speed boost for Linux hacker boards but not a sudden switch to 64-bit ARM computing. While the Odroid project offers an Ubuntu 64-bit image for the C2, the default Linux distribution released by the Raspberry Pi Foundation is still 32-bit.

An eventual change to 64-bit ARM firmware is inevitable given the fact that the technology offers significantly improved performance. Pressure will also come from more power-efficient, 64-bit x86 chips. Yet, because of the extensive reworking of code required for the changeover, the Raspberry Pi Foundation will commit only to “considering” a change to 64-bit for the Pi’s default Raspbian distribution in the coming months.

Yes Raspberry Pi 3 is definitely 64 bit, they are available for sale right now here:
https://bitcointalk.org/index.php?topic=1419675

The issue is that if the operating system is still 32 bit then it's still in untested unsupported territory for ckpool, irrespective of the hardware being 64 bit.