As I already implied, the software is full of 64bit maths and that will produce a noticeable difference, as will having double the registers in general code.
... and you will find that 5 year old link quite outdated now ... comments about not everyone having 64bit processors and "fewer issues" with 32bit are now wrong.
It's the other way around, fewer issues with 64bit and I'm not sure you can even find 32bit processors online any more.
If you can, you've been given old dodgy hardware.
Now the most relevant point ... if you want to run a pool, and you are trying to skimp on hardware, be well aware that you may lose blocks.
You need a bitcoind, and running one on a small vps is a problem waiting to happen.
Topic: CKPOOL - Open source pool/proxy/passthrough/redirector/library in c for Linux - page 14. (Read 124153 times)
November 30, 2015, 10:38:14 AM
November 30, 2015, 03:35:14 AM
I'm really not sure how a 32bit OS can be more efficient on 64bit hardware ...
Edit: ... and I'll add that mining requires 64bit math quite a bit ... since 4billion really isn't a big enough number
So all that code would be slower.
Edit: ... and I'll add that mining requires 64bit math quite a bit ... since 4billion really isn't a big enough number
So all that code would be slower.
I am not a programmer and I know very little about 32bit vs 64bit programs. However, some years ago when I started to rent VPS for my private web site, I did some readings and testing myself. I have made the conclusion that Linux i386 is more efficient in using the RAM than Linux amd64. Somebody did more thorough tests than me and posted the results on this web page, if you wanted to know that.
November 29, 2015, 06:35:24 PM
Hi Con,
I don't believe that you clearly explained the requirement to use Linux amd64 for your CKPool. The only error I saw from the previous posts is the "unknown type name sa_family_t" from /usr/include/linux/un.h.
Could you please explain in detail which parts on your CKPool require Linux amd64?
The main reason I asked is that, for small VPS it is more efficient - in term of the RAM usage - to use Linux i386 instead of amd64. So it would be helpful to know the impact of compiling and running your CKPool on Linux i386.
Cheers,
Anto
The answer is I don't care so I've not bothered to make sure the code is fine on 32bit architectures and I don't want to care. You have your priorities wrong if you are worried about that on a pool.I don't believe that you clearly explained the requirement to use Linux amd64 for your CKPool. The only error I saw from the previous posts is the "unknown type name sa_family_t" from /usr/include/linux/un.h.
Could you please explain in detail which parts on your CKPool require Linux amd64?
The main reason I asked is that, for small VPS it is more efficient - in term of the RAM usage - to use Linux i386 instead of amd64. So it would be helpful to know the impact of compiling and running your CKPool on Linux i386.
Cheers,
Anto
November 29, 2015, 06:17:50 PM
I'm really not sure how a 32bit OS can be more efficient on 64bit hardware ...
Edit: ... and I'll add that mining requires 64bit math quite a bit ... since 4billion really isn't a big enough number
So all that code would be slower.
Edit: ... and I'll add that mining requires 64bit math quite a bit ... since 4billion really isn't a big enough number
So all that code would be slower.
November 29, 2015, 06:16:33 PM
Hi Con,
I don't believe that you clearly explained the requirement to use Linux amd64 for your CKPool. The only error I saw from the previous posts is the "unknown type name sa_family_t" from /usr/include/linux/un.h.
Could you please explain in detail which parts on your CKPool require Linux amd64?
The main reason I asked is that, for small VPS it is more efficient - in term of the RAM usage - to use Linux i386 instead of amd64. So it would be helpful to know the impact of compiling and running your CKPool on Linux i386.
Cheers,
Anto
The answer is I don't care so I've not bothered to make sure the code is fine on 32bit architectures and I don't want to care. You have your priorities wrong if you are worried about that on a pool. I don't believe that you clearly explained the requirement to use Linux amd64 for your CKPool. The only error I saw from the previous posts is the "unknown type name sa_family_t" from /usr/include/linux/un.h.
Could you please explain in detail which parts on your CKPool require Linux amd64?
The main reason I asked is that, for small VPS it is more efficient - in term of the RAM usage - to use Linux i386 instead of amd64. So it would be helpful to know the impact of compiling and running your CKPool on Linux i386.
Cheers,
Anto
November 29, 2015, 06:11:44 PM
I thought I would see if one of the small project boards would work as a proxy so I compiled it on an Odroid C1 (fedora). Compiled easily with only signed/unsigned warnings and connects just fine to kano.is but I get the following error when a miner finds a share and tries to submit it:
Hi Con,
I don't believe that you clearly explained the requirement to use Linux amd64 for your CKPool. The only error I saw from the previous posts is the "unknown type name sa_family_t" from /usr/include/linux/un.h.
Could you please explain in detail which parts on your CKPool require Linux amd64?
The main reason I asked is that, for small VPS it is more efficient - in term of the RAM usage - to use Linux i386 instead of amd64. So it would be helpful to know the impact of compiling and running your CKPool on Linux i386.
Cheers,
Anto
November 22, 2015, 03:01:10 PM
I just set up the proxy to migrate away from p2pool without having to update each miner to a new URL. There seems to be an issue if the username on the miners contains p2pool difficulty settings such as "/256+256" tacked on to the end of the username. The miners using this technique see the ckproxy as dead.
The slash is illegal in the username and pointless to use with p2pool anyway. The + should work though. 
October 22, 2015, 03:32:37 AM
Please, it's 2015. This is 64 bit code only, but if it's working ignore the error as it's just something to do with your distribution.
Compiled on another system (32-bit too - so the bitness doesn't meter) - now works like a charm :-)
Ok... this explains the problems I have had... Whether it works on a 32 bit system depends on how you use it.
I thought I would see if one of the small project boards would work as a proxy so I compiled it on an Odroid C1 (fedora). Compiled easily with only signed/unsigned warnings and connects just fine to kano.is but I get the following error when a miner finds a share and tries to submit it:
Understood - but I thought I saw a message earlier that someone had compiled it on a 32bit processor and it worked. I expected it wouldn't compile if that were the issue but it does and connects to kano.is with no problem. Just can't submit any shares.
I'll drop the experiment. Thought a simple, cheap, power efficient proxy would be good to run vs having it on one of my servers. It would be good to have a redundant, backup proxy.
I managed to compile and run using debian jessie and
Code:
./configure --without-ckdb
Did not succeed in getting the "-p" proxy to run
It would almost work but the following would appear in the logs and eventually the hashrate on the pool ( kano.is ) would drop off and it would fail to submit shares.
Code:
Invalid json line:1 col:4 pos:4 text: NULL string argument from stratifier.c submit_share:2965
Attempted to send null message to generator in send_proc
The passthrough proxy "-P" does work well in 32 bit. The hashrates add up and each worker shows up on the pool. I have used it for several weeks to combine the connections from miners on different machines.
Code:
Failed to set json object from connector.c connector_stats:782
Invalid json line:1 col:5 pos:5 text: NULL string argument from connector.c connector_stats:784
Failed to set json object from connector.c connector_stats:787
Passthrough:{"runtime": 593}
My advice to anyone ckpool/ckproxy with a 32 bit system is to experiment, test, check the logs and verify that the hashrates correspond at all ends. Difficulty adjustments can complicate the testing.
It would be nice if everything worked without problems on 32 bit systems. Then again, I should probably ditch the old laptops. For the record, I'm running my small ckproxy on an old Compaq Evo N410, Pentium III, 1200MHz ca. 2003.
September 22, 2015, 10:34:19 PM
Question, can i use CKPOOL files to set up my own private pool on a raspberry pi to mine Peercoin solo with rent and home hash?
No idea - we don't support any sort of alt-coin mining at all and no point asking questions about it here.However, any mining needs a full fledged, high performance, hacked bitcoind ... so yeah that, oddly enough, wont run on an rpi.
Quote
However, any mining needs a full fledged, high performance, hacked bitcoind
September 22, 2015, 07:44:55 PM
Question, can i use CKPOOL files to set up my own private pool on a raspberry pi to mine Peercoin solo with rent and home hash?
No idea - we don't support any sort of alt-coin mining at all and no point asking questions about it here.However, any mining needs a full fledged, high performance, hacked bitcoind ... so yeah that, oddly enough, wont run on an rpi.
Quote
However, any mining needs a full fledged, high performance, hacked bitcoind
September 22, 2015, 06:57:38 PM
Question, can i use CKPOOL files to set up my own private pool on a raspberry pi to mine Peercoin solo with rent and home hash?
No idea - we don't support any sort of alt-coin mining at all and no point asking questions about it here.However, any mining needs a full fledged, high performance, hacked bitcoind ... so yeah that, oddly enough, wont run on an rpi.
September 22, 2015, 06:38:09 PM
Question, can i use CKPOOL files to set up my own private pool on a raspberry pi to mine Peercoin solo with rent and home hash?
No idea - we don't support any sort of alt-coin mining at all and no point asking questions about it here.However, any mining needs a full fledged, high performance, hacked bitcoind ... so yeah that, oddly enough, wont run on an rpi.
September 22, 2015, 05:36:42 PM
Question, can i use CKPOOL files to set up my own private pool on a raspberry pi to mine Peercoin solo with rent and home hash?
September 14, 2015, 10:08:59 PM
how do you know if u find a block solo mining solo.ckpool, my ant says it found a block but how do i confirm this?
September 09, 2015, 04:48:29 PM
I have the same problem building (with ckdb) on Debian :
Error: Required library gsl-dev not found. Install it or disable support with --without-ckdb
What changes are needed to enable the build ?
Thanks
You'll have to work out how to translate that to debian if debian has different package names.
September 09, 2015, 11:53:13 AM
I have the same problem building (with ckdb) on Debian :
Error: Required library gsl-dev not found. Install it or disable support with --without-ckdb
What changes are needed to enable the build ?
Thanks
August 12, 2015, 04:48:57 PM
Building a pool on Debian;
Found one issue with building on Debian 8 --- I needed to modify the configure script to get the PostGres support to configure/compile.
...
Seems the GSL library in the Debian 8 repository no longer has main() ; configure needed to be told to also link in gslcblas (which is tested afterward) in order to work.... bit of a kludge on my part to get things to configure.
Then see how -ck did it for postgresql and do something similar and submit a change for configure.acFound one issue with building on Debian 8 --- I needed to modify the configure script to get the PostGres support to configure/compile.
...
Seems the GSL library in the Debian 8 repository no longer has main() ; configure needed to be told to also link in gslcblas (which is tested afterward) in order to work.... bit of a kludge on my part to get things to configure.
*however* looking at the close bindings between ckpool, ckdb and the web code is it even possible to split these onto separate machines ?
The idea is to keep everything loosely coupled to allow any component to be grown/shrunk/replaced; makes for a quick way to tear down and replace any machine that gets compromised.
They use linux sockets, so yeah not really possible with ckdb <-> ckpool with the current code.The idea is to keep everything loosely coupled to allow any component to be grown/shrunk/replaced; makes for a quick way to tear down and replace any machine that gets compromised.
The bitcoind needs to be REAL close since block changes need to be as fast as possible.
Block changes and sending out new work on a block change is so important on any pool, though it would seem that a lot of people can't understand that and mine on slow block change pools ... ... ... their loss.
Sooner or later (in the distant future?
) I'll write a separate (tiny) program as a standard socket that sits in front of ckdb, then it's only a matter of changing some of socket.php to talk to ckdb 'remotely' - i.e. web can be anywhere then.Quote
Also, is any work being undertaken on the web code ? -- there are some tweaks I'd like to make but I don't want to duplicate effort.
? I don't commit often enough ??Quote
Lastly, are you open to any tweaks being submitted as new branches / pull requests on the Bitbucket respository...
Regards,
Nick
Of course, but also you are best to have your own git fork (as I'm sure you do already) so that if you submit changes that aren't what I want, you still have your own version.Regards,
Nick
As I mentioned in the link before, asking in IRC is best regarding lots of questions.
There is a very long list of changes that I keep adding new ones to the list (that I write down any time I think of something) - for all sorts of reasons for each - some minor and some major
August 12, 2015, 11:07:00 AM
Hi Kano,
Seems the GSL library in the Debian 8 repository no longer has main() ; configure needed to be told to also link in gslcblas (which is tested afterward) in order to work.... bit of a kludge on my part to get things to configure.
What you are describing is setting up a proxy that points to both your pool and my pool.
As for when it fails over, well that depends on what happens to the pool.
I didn't think this one through properly... of course it needs to be another bitcoin server for the failover.
I have everything built and working on a single machine now..
The Systems Architect in me wants to break it all up into separate (virtual) machines;
I'd would like to setup:-
*however* looking at the close bindings between ckpool, ckdb and the web code is it even possible to split these onto separate machines ?
The idea is to keep everything loosely coupled to allow any component to be grown/shrunk/replaced; makes for a quick way to tear down and replace any machine that gets compromised.
Also, is any work being undertaken on the web code ? -- there are some tweaks I'd like to make but I don't want to duplicate effort.
Lastly, are you open to any tweaks being submitted as new branches / pull requests on the Bitbucket respository...
Regards,
Nick
Building a pool on Debian;
Found one issue with building on Debian 8 --- I needed to modify the configure script to get the PostGres support to configure/compile.
Works as is (of course) on Ubuntu and Fedora - no idea what the difference would be on debian.Found one issue with building on Debian 8 --- I needed to modify the configure script to get the PostGres support to configure/compile.
Quote
Lastly, should ckpool (in pool mode) support connecting to an upstream pool as backup if the local bitcoind fails --- I tried using kano.is as backup but this did not work...
The pool is a pool, not a proxy.What you are describing is setting up a proxy that points to both your pool and my pool.
As for when it fails over, well that depends on what happens to the pool.
I have everything built and working on a single machine now..
The Systems Architect in me wants to break it all up into separate (virtual) machines;
I'd would like to setup:-
- a VM for (walletless) bitcoin
- a second (walletless) bitcoin server VM (if/when I go 'live') for failover
- ckdb + postgres server
- warm standby ckdb + failover postgres server
- a ckpool server
- a web server
- a data backup server (literally just software and storage to backup to)
*however* looking at the close bindings between ckpool, ckdb and the web code is it even possible to split these onto separate machines ?
The idea is to keep everything loosely coupled to allow any component to be grown/shrunk/replaced; makes for a quick way to tear down and replace any machine that gets compromised.
Also, is any work being undertaken on the web code ? -- there are some tweaks I'd like to make but I don't want to duplicate effort.
Lastly, are you open to any tweaks being submitted as new branches / pull requests on the Bitbucket respository...
Regards,
Nick
August 10, 2015, 02:49:26 AM
Building a pool on Debian;
Found one issue with building on Debian 8 --- I needed to modify the configure script to get the PostGres support to configure/compile.
Works as is (of course) on Ubuntu and Fedora - no idea what the difference would be on debian.Found one issue with building on Debian 8 --- I needed to modify the configure script to get the PostGres support to configure/compile.
Lastly, should ckpool (in pool mode) support connecting to an upstream pool as backup if the local bitcoind fails --- I tried using kano.is as backup but this did not work...
The pool is a pool, not a proxy.What you are describing is setting up a proxy that points to both your pool and my pool.
As for when it fails over, well that depends on what happens to the pool.
August 10, 2015, 02:16:07 AM
Building a pool on Debian;
Found one issue with building on Debian 8 --- I needed to modify the configure script to get the PostGres support to configure/compile.
The VM running CKProxy crashed overnight; I'm investigating what caused this....
Would it be of use if I were to provide my notes on getting a fully functional node working for inclusion in the git repo ?
Lastly, should ckpool (in pool mode) support connecting to an upstream pool as backup if the local bitcoind fails --- I tried using kano.is as backup but this did not work...
Found one issue with building on Debian 8 --- I needed to modify the configure script to get the PostGres support to configure/compile.
The VM running CKProxy crashed overnight; I'm investigating what caused this....
Would it be of use if I were to provide my notes on getting a fully functional node working for inclusion in the git repo ?
Lastly, should ckpool (in pool mode) support connecting to an upstream pool as backup if the local bitcoind fails --- I tried using kano.is as backup but this did not work...
Jump to: