 Show Posts
|
|
Pages: [1] 2 »
|
thread 3: reward monitor offline
The program once in a while tries to refresh fetching what the current rewards are for the various pools. Some of the parsers are currently broken, i.e. Eligius (it tries to look them up for /us/ and /eu/). Every time an error happens there, the thread dies. You can find out what caused by scrolling back in the log and seeing what error messages there were between when it was last online, and the first time off-line. Effin' threads. |
|
|
|
Mea culpa. The culprit is the following: if (!($time=~/^\d+$/ and $rate=~/^\d+$/ and $shares=~/^\d+$/ and $rate>0 and $shares>0 and $time>0)){
Unfortunately it wants an _integer_, rather than a number with a dot, for the rate. As such, the code should be (split it for readability): $time=~s/^.*"duration":(\d+).*$/$1/;
$shares=~s/^.*"shares_this_round":(\d+).*/$1/;
$rate=~s/^.*"hashrate":(\d+).*/$1/;
$rate = int($rate/10**9); # this was: $rate /= 10**9, which caused the floating point "error"
Sorry, apologies, head on a plate, etc.etc. |
|
|
|
Nope, I see this directly at bitcoins.lc web site stats page. Also see them rejected in multipool's log. [...]
I have not yet gotten into the spaghetti code to see what, if anything, might be going on...
I had similar issues; they stem from the fact that Multipool.pl uses the "local" bitcoind to know when there is a new block. IIRC, it also does not completely clear up the queue on a new block received (as threads have to pick that up). As such, the following scenarios may develop: - the miner receives the long poll, and the miner does _not_ clear its queue / request more work => nothing to do with Multipool.pl but I think phoenix did that  -- you can verify this by seeing if the rejects are clustered after a long poll. - your bitcoind sees the block & notifies the miners at the same time as all the pools you're getting work from also see it; all is well as the new work fetched by Multipool.pl is pristine and new. - your bitcoind sees the block & notifies the miners PRIOR to a specific pool also realising there is a new block: your miners will request Multipool.pl more work, which in turn will straightaway request it from the pool (which would give work for the previous block); the pool finally realises there's a new block; your miners finish working those works and give them back to Multipool.pl which gives them back to the queue: rejected. - your bitcoind sees the block & notifies the miners AFTER a specific pool realised there is a new block; the miners probably had already asked for "good" work but instead end up dumping work which isn't necessarily stale. Additionally to that, Multipool.pl's handling of whether a share was already sent or not did not work properly. I merely ripped off that part of the code, saying " I will pass on to the pools whatever my miner gives me ". Reduced rejections a bit, but not enough -- reasons above. The only way I see to fix the above is to have Multipool.pl have one longpoll connection per pool, and having it invalidate work queue-by-queue depending on whether it received a longpoll "ping" from that queue or not. After all, if the queue has not yet realised there is a new block, shares from the previous block would still be considered valid by them, _and_ they would not give a new block's work unless they know there is a new block. Multipool.pl's code uses basic sockets and select(), and... threads.. I have been toying with the idea of doing the above using AnyEvent (async IO for Perl), but would only do/finish that for a _personal_ multipool switcher rather than something multiple people would connect to and distribute payments to etc. I kind of gave up on beating Multipool.pl into submission not for lack of trying but rather as it came to a point where it'd be easier to rewrite most of it rather than trying to fix it. I develop in Perl for a living, so it's not like I can't read the code. There are too many places where I know what the code does, but have no clue as to the reason _why_ it's doing that  I will likely soon release what I am currently using for my PC, which has only _one_ graphics card. It uses bits of the algorithm from Multipool.pl but rather than getting shares and distributing them to miners, has the _miner itself_ connect to the best/wanted pool. I think there's another thread for another program that does this already for multiple cards as well, but it's a bit overkill for what I needed. I am not sure if enough people would need a "personal multipool switcher which distributes shares", which is what Multipool.pl does, other than for having its code somewhere in Github so multiple such pool hopper pools can be created by anybody.. to warrant developing a better pool hopper that works that way. After all, if there are two/three pools like that, what is the point? Pointing them at each other? |
|
|
|
No i meant, i set multipool to mine from pool 1,2,3,4,5. How do i get my BTC from the 5 pools to my wallet? To pay users, create a "main" account, move funds to it, and run: This part. Is it automatic? If you are using Multipool.pl alone, you don't need to: just log in on each of the five pools' websites, and have them pay the balance to your wallet. That part is only necessary if you run Multipool.pl as a service for other users, too. |
|
|
|
Getting close now to a release. Need to find a way to include the kernel files in distdir and install.
Con, would you consider adding or receiving a pull request to get the status line to be similar to phoenix's, and add a couple more info points: - Total getworks received in the current run - Efficiency %, calculated as percentage of getworks received vs accepted (can be >100%) in the current run - Utility (for lack of a better name), calculated as being the number of accepted per minute in the current run (varies wildly at first, should stabilise after a bit). All the above needs is: - an unsigned to hold the total getworks received - one more %d per log printf and/or _info for the total getworks - two more %.2f per log printf and/or _info for the efficiency % and utility: - Efficiency: getwork_requested ? cgpu->accepted * 100 / getwork_requested : 0.0 - Utility: accepted/total_secs*60 cgminer's MHash/s seem to wildly differ from other miners I have. The "efficiency" and "utility" are probably better measures of how the miner has performed in the long run than "just" the MHash. Especially the "Utility", as (together with "accepted") is the only measure of how well the miner performs with regards to submitting the shares upstream. |
|
|
|
1. bitcoind.conf
Enter your bitcoind username and password here, on a single line, separated by a space.
(assuming bitcoind is running on 127.0.0.1:8332)
any idea where the bitcoind files are on deb? Do I need to get the username and password from bitcoind? You need to create a file named bitcoind.conf *in the same directory as Multipool.pl*, containing *in one single line*, *separated by a space* the username and password you need to use to connect to the local bitcoind instance. Much of the confusion comes from Multipool.pl naming that config file the same name as the one used by bitcoind Your "real" bitcoind.conf (the one that controls which username and password bitcoind is to accept) is usually found in ~/.bitcoin/bitcoind.conf and the wiki explains how to put info there. Example: $ ls Multipool.pl # we are in the same directory where Multipool.pl is
Multipool.pl
$ cat ~/.bitcoin/bitcoin.conf
server=1
rpcuser=myusername
rpcpassword=mypassword
rpcallowip=192.168.1.*
rpcport=8332
gen=0
$ cat bitcoind.conf
myusername mypassword
$
as you see above, the "local" bitcoind.conf needs to contain the username and password from the "real" bitcoind.conf, separated by a space. |
|
|
|
Do we have an expectation that the bitcoins-lc shares in multiclone will turn into actual shares?
It is my understanding that the code that deals with the shares for bitcoins-lc needs to be rewritten for those to be distributed, as it is not current / does not scrape things correctly. The pool owner could always pull out a spreadsheet and calculate those manually, though. |
|
|
|
Installing all prerequisite modules without being root. Prerequisites: * a new user account, here "teensy". * gcc needs to be installed * Multipool.pl (to test it works) First, we fetch "cpanm", best practice Perl module installer: teensy:~$ curl -L http://cpanmin.us > cpanm 2>/dev/null
teensy:~$ chmod +x cpanm We will then install the prerequisites under the current directory's "lib" subdirectory. This is done via the parameter "-l lib" to cpanm: teensy:~$ ./cpanm -l lib JSON::RPC::Client
--> Working on JSON::RPC::Client
Fetching http://search.cpan.org/CPAN/authors/id/M/MA/MAKAMAKA/JSON-RPC-0.96.tar.gz ... OK
Configuring JSON-RPC-0.96 ... OK
Building and testing JSON-RPC-0.96 ... OK
Successfully installed JSON-RPC-0.96
1 distribution installed Finance::Bitcoin is a signed package, we need to make sure we have the right signature or it will hang and cause grief. teensy:~$ gpg --recv-keys --keyserver keyserver.ubuntu.com 6A2A7D39
gpg: directory `/home/teensy/.gnupg' created
gpg: new configuration file `/home/teensy/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/teensy/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/teensy/.gnupg/secring.gpg' created
gpg: keyring `/home/teensy/.gnupg/pubring.gpg' created
gpg: requesting key 6A2A7D39 from hkp server keyserver.ubuntu.com
gpg: /home/teensy/.gnupg/trustdb.gpg: trustdb created
gpg: key 6A2A7D39: public key "Toby Inkster <mail@tobyinkster.co.uk>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 Once the key has been imported, we can install it: teensy:~$ ./cpanm -l lib Finance::Bitcoin
--> Working on Finance::Bitcoin
Fetching http://search.cpan.org/CPAN/authors/id/T/TO/TOBYINK/Finance-Bitcoin-0.002.tar.gz ... OK
Configuring Finance-Bitcoin-0.002 ... OK
Building and testing Finance-Bitcoin-0.002 ... OK
Successfully installed Finance-Bitcoin-0.002
1 distribution installed Last prerequisite: teensy:~$ ./cpanm -l lib Math::Integral::Romberg
--> Working on Math::Integral::Romberg
Fetching http://search.cpan.org/CPAN/authors/id/B/BO/BOESCH/Math-Integral-Romberg-0.04.tar.gz ... OK
Configuring Math-Integral-Romberg-0.04 ... OK
Building and testing Math-Integral-Romberg-0.04 ... FAIL
! Installing Math::Integral::Romberg failed. See /home/teensy/.cpanm/build.log for details. It will fail, at least it did for me.. as it tried to install it under /usr/. Bad boy, no cookie! Since it's a pure-Perl module, we and it _did_ pass the tests (run cpanm with -v if you don't believe it), just copy the module over to the local lib: teensy:~$ cp -Rfv ~/.cpanm/latest-build/Math-Integral-Romberg-0.04/blib/lib/* lib/lib/perl5/
`/home/teensy/.cpanm/latest-build/Math-Integral-Romberg-0.04/blib/lib/Math' -> `lib/lib/perl5/Math'
`/home/teensy/.cpanm/latest-build/Math-Integral-Romberg-0.04/blib/lib/Math/Integral' -> `lib/lib/perl5/Math/Integral'
`/home/teensy/.cpanm/latest-build/Math-Integral-Romberg-0.04/blib/lib/Math/Integral/Romberg.pm' -> `lib/lib/perl5/Math/Integral/Romberg.pm' We are almost set; we need to know which PERL5LIB to use when launching Multipool.pl. Check the subdirectories of lib/lib/perl5 for the architecture-specific subdirectory: teensy:~$ ls lib/lib/perl5/
Finance JSON JSONRPC.pm Math x86_64-linux-gnu-thread-multi In this case, mine is "x86_64-linux-gnu-thread-multi". The environment var PERL5LIB needs to be set to _both_ lib/lib/perl5 _and_ the architecture-specific path. Once that's done, we can use "perl -c" to ensure no other dependencies are needed: teensy:~$ PERL5LIB="lib/lib/perl5/x86_64-linux-gnu-thread-multi:lib/lib/perl5" perl -c Multipool.pl
Multipool.pl syntax OK You can either launch Multipool.pl that way, or amend Multipool.pl to have the correct "use lib" on the line under the line which reads "use strict;": use strict;
use lib 'lib/lib/perl5', 'lib/lib/perl5/x86_64-linux-gnu-thread-multi'; Use your architecture-specific subdirectory, of course. Happy hopping! |
|
|
|
Also, even though I removed the ser vers from the list, they still appear in the multipool terminal as trying to connect. How would I go about removing them so I can speed things up with servers that connect?
Multipool will only read the accounts and pools at startup, so you need to kill it and start it again, if you want it to pick up new pools or remove old pools. I think I should put more time into my replacement.. assuming there's enough interest and people aren't just using this to solo mine different pools. |
|
|
|
my multipool tells me that minecoin is offline.
I am currently getting some disconnections from them, too; and several spurious rejections. The way Multipool seems to deal with that is it pushes "down" the pool, until it considers it offline. Could be either offline per se, or the script giving up. I basically copied your script into the "pools.conf", opened the port and then added the minecoin info to "accounts.conf".
Just the stanza I wrote, between "minecoin" and "utility_1", I hope. Only one newline between stanzas. Ensure your user/pass are correct for that miner on the accounts.conf... The script should show when it is that it's putting a pool offline, though: check the scroll / logs to see if it gave you any more info. Again, sorry but I did not use the script as-is myself. I did modify/butcher a fair bit of it. I still have the original which I am using to help you guys out. I was also wondering if if you can help with triplemining? Iv tried but i just get errors and problems all over because im doing it incredibly wrong.
If you have a URL where they provide some statistics... by the cursory look I gave, there's only the "blocks found" page, which only contains information in human terms ("1 days ago")... PM me in case you need further help; post a "solution" once you get something working. |
|
|
|
Would it be possible to 7zip up the virtual machine and upload using a Torrent?
I am pretty sure people would send you a coin for the download, I would for sure...
If you already have a distro setup, you can create a new user and follow the instructions I gave above for installing JSON::RPC::API in a local lib, and simply install the other prerequisite modules via it: Finance::Bitcoin::API and Math::Integral::Romberg being the other two ones I think. In order to do that, the linux distro -does- need to have a working compiler, though. Creating a virtual machine for this multipool looks a bit overkill to me.. |
|
|
|
I never did get the perl CPAN dependencies (...)
Can't locate JSON/RPC/Client.pm
I appreciate the gentleman running Multiclone but I'd like to run one myself for my own use.
I guess I need to try again sometime, perhaps with a newer distro than Centos 5
Why not today? Use cpanm ( http://search.cpan.org/~miyagawa/App-cpanminus-1.4008/lib/App/cpanminus.pm) to install modules -locally- rather than as root. Example, for Multipool I created a new user, disabled password and all, got the source and then installed the dependencies in a "local lib" with cpanm. I'll re-do bits of it for you, so you can get comfortable with the process  I'll first create a new user: root@xxx:~# adduser --disabled-password teensy
Adding user `teensy' ...
... Switch to it: Fetch cpanm: teensy@xxx:~$ curl -L http://cpanmin.us > cpanm
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 163k 100 163k 0 0 78241 0 0:00:02 0:00:02 --:--:-- 377k
teensy@xxx:~$ chmod +x cpanm Tell it to install JSON::RPC::Client in the local ./lib directory: teensy@xxx:~$ ./cpanm -l ./lib JSON::RPC::Client
--> Working on JSON::RPC::Client
Fetching http://search.cpan.org/CPAN/authors/id/M/MA/MAKAMAKA/JSON-RPC-0.96.tar.gz ... OK
Configuring JSON-RPC-0.96 ... OK
Building and testing JSON-RPC-0.96 ... OK
Successfully installed JSON-RPC-0.96
1 distribution installed Now, if you look under lib/ you will see there are a bunch of directories which you need added to Perl's path for libraries. In my case, these are: lib/lib/perl5, and lib/lib/perl5/x86_64-linux-gnu-thread-multi. To see it worked, $ perl -MJSON::RPC::Client -e1
Can't locate JSON/RPC/Client.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .).
BEGIN failed--compilation aborted.
$ PERL5LIB="lib/lib/perl5/x86_64-linux-gnu-thread-multi:lib/lib/perl5" perl -MJSON::RPC::Client -e1
So, what you then can do is either: * use that PERL5LIB= line before launching Multipool.pl, a la: $ PERL5LIB=xxxx perl Multilib.pl, or * properly install cpanm and local::lib (search for tutorials on the web, or ask me for more info), or * modify Multilib.pl to have " use lib './lib/lib/perl5', 'lib/lib/perl5/x86_64-linux-gnu-thread-multi'; " at its beginning after "use strict" There you go |
|
|
|
We need to add more pools to pool.conf. I have no idea how to parse the pools API.
The file pools.conf is quite straightforward; for example: slush
api.bitcoin.cz:8332
https://mining.bitcoin.cz/stats/json/
$time=~s/.*round_duration": "//; $time=~s/".*//; $time=parse_time($time); $rate=~s/.*ghashes_ps": "//; $rate=~s/(\.\d*)?".*//; $shares=~s/.*shares": //s; $shares=~s/,.*//s;
utility_2 The first line of a stanza is the pool's name; second is the RPC port (the one the miners use), the third is a URL which the Multipool.pl will fetch in order to gather statistics, then some code whose purpose is to get the time since last block found, total shares and total rate in GHash, and lastly the "utility" function to be used to calculate the utility for a pool. The line of code is messy, but the idea is that it is executed in a context in which $_ (the topic variable) is aliased to the data received from the URL above, and it needs to "output" three variables: * $time, in seconds, indicating how long ago the last block was found; * $rate, in GHashes/s, indicating the pool's speed in GH/s * $shares, indicating how many shares the pool has currently mined. An example, for mineco.in: The stats are in JSON: $ curl https://mineco.in/stats.json
{"hashrate":86362247950,"users":568,"blocks_found":16,"shares_this_round":2102867,"last_block":{"found":1309779953,"user":"mau","shares":1461964,"duration":79213}} The info we're looking for is the number after "hashrate", but it's in hashes per second so it needs to be divided by 10^6; the number after "duration" and the number after "shares_this_round". The way you can test the line of code that goes in the config is via: curl URL | perl -lne' $time=$shares=$rate=$_;
THAT LINE OF CODE HERE;
print "Rate: $rate"; print "Time: $time"; print "Shares: $shares"; '
so for example: $ curl https://mineco.in/stats.json | perl -lne'
$time=$shares=$rate=$_;
$time=~s/^.*"duration":(\d+).*$/$1/;
$shares=~s/^.*"shares_this_round":(\d+).*/$1/;
$rate=~s/^.*"hashrate":(\d+).*/$1/;$rate/=10**9;
print "Rate: $rate"; print "Time: $time"; print "Shares: $shares"; '
Rate: 86.069951565
Time: 79213
Shares: 2097252
There you go The stanza then becomes: minecoin
mineco.in:3000
https://mineco.in/stats.json
$time=~s/^.*"duration":(\d+).*$/$1/; $shares=~s/^.*"shares_this_round":(\d+).*/$1/; $rate=~s/^.*"hashrate":(\d+).*/$1/;$rate/=10**9;
utility_1 Check out the different utility_ functions, but usually utility_1 seems to work fine. If you want me to do others do not hesitate to PM me or try doing them yourselves; above I have explained how. (edited: wrapped in code blocks) |
|
|
|
|
I asked the original poster what license was the code under, as I started rewriting bits of it to be more.. Perlish.. and wanted to be able to release my modifications under the proper license.
I ended up ripping off completely the part that distributes to accounts, and had been running it for a while locally. All was good.
Unfortunately I kept getting a high number of stales/rejections due to the network code that deals with sending proof of work, which is a bit awkward..
I had been thinking of writing something similar using more modern modules like AnyEvent, but lacked the time. Will likely do this if there is enough want.
On the other hand, I went instead to a simpler system which periodically checks which is the best pool to switch to, kills the miner and has it switch to the chosen pool.
I don't think everybody needs both the pool-hopping *and* the shares distribution: I'd be creating the pool hopping thing only, for one to use with their own miners.
I am not entirely sure if the idea of having multipool sites "up" would create problems for the pools, as a number of GHash suddenly start hopping from one to the next.. with what has been happening as of late with DDOSes on the pools..
Still, if anybody is running multipool locally and needs a hand with some small fixes to the current multipool code, I'd be happy to oblige -- PM me for info.
|
|
|
|
|
Wow, this lasted long.... it's now in the hands of a domain squatter :|
|
|
|
|
For my 5770, phoenix is the only one that reaches speeds of 218.00 MH/s. All the others lag behind. I am currently using the svn version, and launching it as follows: LD_LIBRARY_PATH=/opt/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/ python phoenix.py -u http://user:pass@host:port/ -k phatk DEVICE=0 BFI_INT VECTORS FASTLOOP=false AGGRESSION=13 WORKSIZE=128 -v I suggest you play with: - whether sdk 2.1 or 2.4 is best (if you use phatk, you need 2.4) - whether VECTORS makes a change for you or not - WORKSIZE depending on the card either 128 or 256; despite what the wiki says, I get better speeds with 128. - the speed of your memory -- despite common claims, for me 960 was the best rather than 600 (although I could not go lower than 600) Not too shabby: $ aticonfig --odgt --adapter=all Adapter 0 - ATI Radeon HD 5700 Series Sensor 0: Temperature - 73.00 C $ aticonfig --odgc --adapter=all Adapter 0 - ATI Radeon HD 5700 Series Core (MHz) Memory (MHz) Current Clocks : 960 960 Current Peak : 960 960 Configurable Peak Range : [600-960] [600-1445] GPU load : 99% |
|
|
|
|
What license is the code under?
I've downloaded it and started rewriting some ugly bits, removing embedded defaults, using JSON for the config files, etc.
I would like to make my changes available, but would rather know the license they'd be supposed to be under.
I'd then be putting the changes on Github as soon as I get them done, and I know which license they're supposed to be under.
|
|
|
|
Start the miners each in their own GNU Screen sessions [..] will allow users to view the miners though SSH.
I use tmux for my miner(s), as: - it can be split horizontally/vertically, so I can have a number of miners in one "window" - its launch can be scripted, so you can have one .sh script launch a number of miners each with their own details *and* detach the whole - it can be scripted and the buffer saved somewhere, to be later handled via other GNU tools For example: on screen 0, window 1, pane 0 I have a miner; on pane 1 another. echo "Miners' info:"
for pane in 0 1; do
tmux capture-pane -t 0:1.$pane # captures the contents of the pane for the 1st miner
tmux save-buffer /tmp/buff-01$pane # saves it to a file
echo "Miner $pane: $(tail -n 1 /tmp/buff-01$pane)" # gets the latest line, usually the one with MHash/sec
done
I also modify the miners to report found/rejected blocks on STDERR, then munge it with some Perl and display the graph on a site, but having only one graphics card I'm not sure how useful the thing is to you guys |
|
|
|
|
