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:


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):


Sorry, apologies, head on a plate, etc.etc.

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?

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.

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.

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:


as you see above, the "local" bitcoind.conf needs to contain the username and password from the "real" bitcoind.conf, separated by a space.

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:


We will then install the prerequisites under the current directory's "lib" subdirectory. This is done via the parameter "-l lib" to cpanm:


Finance::Bitcoin is a signed package, we need to make sure we have the right signature or it will hang and cause grief.


Once the key has been imported, we can install it:


Last prerequisite:


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:


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:


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:


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 your architecture-specific subdirectory, of course.

Happy hopping!

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.

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.


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.

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.

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

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:


Switch to it:

Fetch cpanm:

Tell it to install JSON::RPC::Client in the local ./lib directory:


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,


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

The file pools.conf is quite straightforward; for example:


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:


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:

so for example:

There you go

The stanza then becomes:


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.

They used to have the API URLs listed but a recent change a couple weeks ago removed the directory listing.

The URLs are still accessible and AFAIK usable:
https://britcoin.co.uk/api/getTrades.php
https://britcoin.co.uk/api/getDepth.php
https://britcoin.co.uk/api/ticker.php

Thanks!

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.



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

I run my DiabloMiner inside a tmux session (same as screen, but better).
I have to always export DISPLAY=:0.0 before launching a new session if I create a new tmux window.

There is a fairly complete guide about DiabloMiner here: http://forum.bitcoin.org/?topic=3356.msg47489#msg47489

If you have Crossfire, you should allegedly turn that *off*: http://forum.bitcoin.org/index.php?topic=7167.msg105782#msg105782

Check what the env var $COMPUTE is, as when that is set it supersedes $DISPLAY for ATI computation.

https://en.bitcoin.it/wiki/Mining_hardware_comparison only lists other miners for the 6990, not DiabloMiner.

Hope anything above helped...