Pages:
Author

Topic: Pooled/Remote Mining - Open Source - Updated 2010-12-24 - page 3. (Read 59069 times)

member
Activity: 103
Merit: 17
The first post has been updated with a new release.

The server will now send the contribution type to the clients, and the clients will display it upon connecting to the server.  The server will also save timing stats to a text file periodically so that we can narrow down what the bottlenecks are.  If you are running a server, please post your timing stats after the server has been up for a while.

The clients are now multi-threaded, so you won't have to load the CPU client multiple times if you have more than 1 CPU core.  There is also an OpenCL client included.
legendary
Activity: 1078
Merit: 1005
The amount of bitcoin's being reported since the update from about a week or so ago seems to be cut in half.  This was brought up before and it was quickly disregarded.  So now I'm asking the other people that are running clients that are contributing to the pool to look at their numbers and see if it's off for you too.

A new block was generated by the pool today. The total amounts distributed in the recently generated block can be seen here: http://blockexplorer.com/b/97017
hero member
Activity: 532
Merit: 505
Quote
WHY AM I ONLY GETTING "8.10162 BTC if this block is solved"?  I should be getting 18.535,
because! 

seriously, it's already been said in the other thread,
besides that, it's all in the readme-file, shame on you  Wink

theres 2 options for the distribution-type of coins,
server-admin chooses either 'contributed' or 'connected'.

'..."connected" will distribute coins only to those clients that were connected when the block being solved was created....'
while
'..."contributed" will accrue all hashes sent to the server for a given address since the last generated block...'

the pool currently runs in "contributed"-mode, the longer you'r online, the closer you'll get to your 18.535btc.
sr. member
Activity: 1344
Merit: 264
bit.ly/3QXp3oh | Ultimate Launchpad on TON
This is a cross thread posting.  Sorry in advance.

The amount of bitcoin's being reported since the update from about a week or so ago seems to be cut in half.  This was brought up before and it was quickly disregarded.  So now I'm asking the other people that are running clients that are contributing to the pool to look at their numbers and see if it's off for you too.

Here we go. 
Here's the numbers being reported @ the time of writing this.
Server Status : 96 clients, 203464 khash/s
Address will receive 8.10162 BTC if this block is solved

I have a total of eight remote mining instances running. 
8733+9600+8733+9600+8966+9600+7833+12366 = 75,431 khash/s between my two boxes which is CPU's and GPU's combined.

75,431 khashes (my systems) / 203,464 (server khash/s) = 0.3707338890417961
0.3707338890417961 * 100 = %37.07338890417961

That's about %37.07 (0.3707.. * 100) of the total khash/s that the server is reporting.

Now we show what %37.07 of 50 bitcoins should be.
For every 1% of a block (50 bitcoins) is 0.5 bitcoins.
50(bitcoins/block) / 100(%) = 0.5 (bitcoins/block)
0.5 * 37.07% = 18.535 bitcoins

WHY AM I ONLY GETTING "8.10162 BTC if this block is solved"?  I should be getting 18.535, which is about what I saw before the update a week ago.  I know there has been talk about distribution methods, but I don't care what you call it when the math is wrong and the amount paid out and is far less than what it should be.  If been contributing to the pool non-stop since it started. I even crashed the server a few times because by throwing about 64 CPU's and 3 GPU's at it, but now I'm back to 6 CPU's and 3 GPU's.
It was very obvious when this happened because the amount of BTC I would receive was at least cut in half.

Here's a some tables for others to quickly look up about what range they should be getting back. 
To get a percentage use this equation: (your khash/s) divided by (server khash/s) then multiply it by 100.

CPU USERS LOOK HERE
BITCOINS PER PERCENTAGE (%.05 increments) BETWEEN 0.01% and 1.00%
50 * 0.01% = 0.005 bitcoins
50 * 0.05% = 0.025 bitcoins
50 * 0.10% = 0.050 bitcoins
50 * 0.15% = 0.075 bitcoins
50 * 0.20% = 0.100 bitcoins
50 * 0.25% = 0.125 bitcoins
50 * 0.30% = 0.150 bitcoins
50 * 0.35% = 0.175 bitcoins
50 * 0.40% = 0.200 bitcoins
50 * 0.45% = 0.225 bitcoins
50 * 0.50% = 0.250 bitcoins
50 * 0.55% = 0.275 bitcoins
50 * 0.60% = 0.300 bitcoins
50 * 0.65% = 0.325 bitcoins
50 * 0.70% = 0.350 bitcoins
50 * 0.75% = 0.375 bitcoins
50 * 0.80% = 0.400 bitcoins
50 * 0.85% = 0.425 bitcoins
50 * 0.90% = 0.450 bitcoins
50 * 0.95% = 0.475 bitcoins
50 * 1.00% = 0.500 bitcoins

GPU USER'S LOOK HERE
BITCOINS PER PERCENTAGE (%5 increments) BETWEEN 1% and 100%
-------------------------------------------
50 * 1% = 0.5 bitcoins
50 * 5% = 2.5 bitcoins
50 * 10% = 5 bitcoins
50 * 15% = 7.5 bitcoins
50 * 20% = 10 bitcoins
50 * 25% = 12.5 bitcoins
50 * 30% = 15 bitcoins
50 * 35% = 17.5 bitcoins
50 * 40% = 20 bitcoins
50 * 45% = 22.5 bitcoins
50 * 50% = 25 bitcoins
50 * 55% = 27.5 bitcoins
50 * 60% = 30 bitcoins
50 * 65% = 32.5 bitcoins
50 * 70% = 35 bitcoins
50 * 75% = 37.5 bitcoins
50 * 80% = 40 bitcoins
50 * 85% = 42.5 bitcoins
50 * 90% = 45 bitcoins
50 * 95% = 47.5 bitcoins
50 * 100% = 50 bitcoins


IS ANYONE ELSE SEEING THIS, OR HAVING I COMPLETELY LOST MY MIND?
newbie
Activity: 35
Merit: 0
For the CUDA miner arguments, I can see what -gpu=X values might be as well as -aggression=X, and perhaps -gputhreads=X is obvious.  But what would go in -gpugrid=X?
legendary
Activity: 1078
Merit: 1005
On Fedora (what I have) it's "openssl-devel", and yes I have it.

Fedora used to configure openssl so ecdsa is not included:

https://bugzilla.redhat.com/show_bug.cgi?id=319901

Possibly they still do.
legendary
Activity: 1078
Merit: 1005
/home/mithrandir/Downloads/bitcoin-pool/src/remote/../headers.h:41:27: fatal error: openssl/ecdsa.h: No such file or directory

Do you have the libssl development files installed? On a debian based system this is libssl-dev.
newbie
Activity: 35
Merit: 0
That is the problem.  He didn't have the developer drivers.  Now it's working.  I'm getting ~5600 khash/s.  He's getting ~2700 khash/s.
pc
sr. member
Activity: 253
Merit: 250
That binary worked for me, but for another user, he got:

Code:
/Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/cuda/bitcoinminercuda.cpp(43) : cudaSafeCall() Runtime API error : CUDA driver version is insufficient for CUDA runtime version.

I don't know the exact particulars of his hardware.
Well, my wild guess is that he needs the latest "Developer Drivers for MacOS" from http://developer.nvidia.com/object/cuda_3_2_downloads.html

If that's not it, then I guess my build isn't compatible in some other way.
newbie
Activity: 35
Merit: 0
Here's what I think I did to get the CUDA version to compile on a Mac. Note that this is definitely the wrong way of solving the problems I was having compiling.

  • In src/remote/cuda/bitcoinminercuda.cpp, just after the includes, I added inline int OutputDebugStringF(const char* pszFormat, ...) {return 0;}
  • In src/gpucommon/gpurunner.h, just below #define _bitcoin_gpu_runner_ added #include "../headers.h"

It's using one CPU generating, and my system is lagging now, and it's certainly more than I was getting just generating on one CPU before, but it's still only a few thousand khash, not the hundreds of thousands that it seems some others get using a GPU. Perhaps my video card isn't fancy enough, or I've horribly screwed up some settings somewhere.

Binary is located at http://dl.dropbox.com/u/16187822/bitcoinr-cuda for those who have a 64-bit Intel Mac that's close enough to mine that it works for them.

That binary worked for me, but for another user, he got:

Code:
/Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/cuda/bitcoinminercuda.cpp(43) : cudaSafeCall() Runtime API error : CUDA driver version is insufficient for CUDA runtime version.

I don't know the exact particulars of his hardware.
hero member
Activity: 532
Merit: 505
i thought today, that 17-18M is a bit slow for my GTX260 (not to complain, it works and that's better than nothing),
then i noticed, that the miner only does 50% GPU Load, so i started a 2nd instance.

good thing is, that this also works,
bad thing is, that, as i mentioned before, a single instance also loads 50% of the CPU, so with 2 instances i'm at 100% CPU, which might be the cause that both instances only load the GPU up to 70%.
still a little improvement, its 2x ~13M now, but also lots of 'wasted' energy on the CPU and of course a slower system.

anyway, just wanted to let you know.

newbie
Activity: 7
Merit: 0
I built the needed boost stuff from source, and set BOOST_ROOT.
Now it compiles but the linker crashes.

It's picking up old boost libraries and/or headers. I had this issue too. I hardcoded the makefile to pick the boost stuff I wanted.



Took a while to find all the places, but got it working now. Thanks!
legendary
Activity: 1078
Merit: 1005
Just the server.  Any client since the 2010-12-02 release should connect and work fine.

Thanks, I've switched and it looks like it's working fine.
newbie
Activity: 8
Merit: 0
This version of the CUDA pooled mining client gets about half of the performance of m0m's client and comparable clients. I am sure with subsequent revisions that will get better. That is part of the development process!
pc
sr. member
Activity: 253
Merit: 250
Here's what I think I did to get the CUDA version to compile on a Mac. Note that this is definitely the wrong way of solving the problems I was having compiling.

  • In src/remote/cuda/bitcoinminercuda.cpp, just after the includes, I added inline int OutputDebugStringF(const char* pszFormat, ...) {return 0;}
  • In src/gpucommon/gpurunner.h, just below #define _bitcoin_gpu_runner_ added #include "../headers.h"

It's using one CPU generating, and my system is lagging now, and it's certainly more than I was getting just generating on one CPU before, but it's still only a few thousand khash, not the hundreds of thousands that it seems some others get using a GPU. Perhaps my video card isn't fancy enough, or I've horribly screwed up some settings somewhere.

Binary is located at http://dl.dropbox.com/u/16187822/bitcoinr-cuda for those who have a 64-bit Intel Mac that's close enough to mine that it works for them.
pc
sr. member
Activity: 253
Merit: 250
Weird, I installed Berkely DB as described in the osx build file you mentioned, but I still get the db_cxx.h error.  Your binary works on my machine.  Nice work!

I think I had to run the configure for it with --prefix=/usr/local for it to work. I really should have been documenting all the stuff I've tried better while trying to get this to work. I've probably made quite the mess of my machine. Now all that's left is trying to get the CUDA pooled binary built. I'm at the point where I get the error in gpurunner.h listed in the comments at http://www.bluishcoder.co.nz/bitcoin-pool/ which is the next point I'm stumped.

Glad to hear that the binary's working for someone else.
newbie
Activity: 35
Merit: 0
I found https://github.com/doublec/bitcoin-pool/blob/master/src/build-osx.txt which told me how to install Berkley DB, and I managed to build on a Mac with CUDA disabled. I'd like to try CUDA, but the build seems to not quite know where I've installed its Toolkit and SDK, even though CMake does. But I've dug through it enough for one night, and I'm now happily generating with my CPU on the pooled server from my Mac.

The binary I built is at http://dl.dropbox.com/u/16187822/bitcoinr, although I assume you need a 64-bit Intel system at the least to run it, and perhaps there are even more requirements that your system needs to be similar to mine. But I did manage to put just the binary on another Mac and it's running there too, so it seems to be at least somewhat portable.

Weird, I installed Berkely DB as described in the osx build file you mentioned, but I still get the db_cxx.h error.  Your binary works on my machine.  Nice work!
legendary
Activity: 1078
Merit: 1005
I built the needed boost stuff from source, and set BOOST_ROOT.
Now it compiles but the linker crashes.

It's picking up old boost libraries and/or headers. I had this issue too. I hardcoded the makefile to pick the boost stuff I wanted.

member
Activity: 103
Merit: 17
I've updated the first post with the latest release.  The "contributed" distribution method should be working now.  That is the only substantial change in this release.

Does this require remote miner clients to update as well? Or is it just the server?

Just the server.  Any client since the 2010-12-02 release should connect and work fine.
newbie
Activity: 7
Merit: 0
I built the needed boost stuff from source, and set BOOST_ROOT.
Now it compiles but the linker crashes.
Code:
Linking CXX executable bitcoinr
CMakeFiles/bitcoinr.dir/__/src/remoteminermain.cpp.o: In function `__static_initialization_and_destruction_0(int, int)':
remoteminermain.cpp:(.text+0x9e): undefined reference to `boost::system::generic_category()'
remoteminermain.cpp:(.text+0xaa): undefined reference to `boost::system::generic_category()'
remoteminermain.cpp:(.text+0xb6): undefined reference to `boost::system::system_category()'
CMakeFiles/bitcoinr.dir/__/src/remote/remoteminerclient.cpp.o: In function `__static_initialization_and_destruction_0(int, int)':
remoteminerclient.cpp:(.text+0x9e): undefined reference to `boost::system::generic_category()'
remoteminerclient.cpp:(.text+0xaa): undefined reference to `boost::system::generic_category()'
remoteminerclient.cpp:(.text+0xb6): undefined reference to `boost::system::system_category()'
CMakeFiles/bitcoinr.dir/__/src/remote/remoteminerclient.cpp.o: In function `boost::thread::sleep(boost::posix_time::ptime const&)':
remoteminerclient.cpp:(.text._ZN5boost6thread5sleepERKNS_10posix_time5ptimeE[boost::thread::sleep(boost::posix_time::ptime const&)]+0x11): undefined reference to `boost::this_thread::sleep(boost::posix_time::ptime const&)'
collect2: ld returned 1 exit status
make[2]: *** [cmake-bitcoinr/bitcoinr] Error 1
make[1]: *** [cmake-bitcoinr/CMakeFiles/bitcoinr.dir/all] Error 2
make: *** [all] Error 2
Pages:
Jump to: