Quote from: M4v3R on June 29, 2011, 07:09:54 AM

I managed to get it up and running, ...
Edit 2: Resolved that one as well. It required a change in the code, on line 1303 you have to replace multipool.hpc.tw with an hostname you use. It works great so far, thanks!

Great to hear the pool works for other people as well!

Quote from: M4v3R on June 29, 2011, 09:12:00 PM

I experience one problem. After running the Multipool server for few hours, it slows down. The output in the console slows down and then workers are experiencing idle times. Restarting the server helps. Is this a memory leak, or maybe the log file slows whole thing down? Anyone noticed it?

The pool worked fine for several days at a time with ~30 users connected. What is the cpu/memory usage for Multipool.pl and bitcoind?

There is one correction I should make. On line 520 replace:

Code:

my $pool_name=$ranked_pools[$i]->{name};

with

Code:

my $pool_name=$pool->{name};

. It is some threading race issue I was working on which crashes the pool once a day or so.

Quote from: Sukrim on June 29, 2011, 01:36:02 PM

I think we'll need to move the pool specific functions ([poolname]_rewards) to the pools.conf file, to be a bit more portable/extendable... Maybe something like a "plugin" system.

Unfortunately I didn't yet code a lot in Perl and porting all this stuff to Python is a task for later (at least for me). Would be great to at least have a proper git repo etc. running!
Instead of solo something like Eligius with PPS + nearly 0 fees would be interesting (if people don't exploit it by withholding winning shares that is...) or maybe even namecoin.

I'll configure the repo properly at some point. The computer I used didn't have git, and I was surprised to find out that github doesn't have any web upload interface that I could see, besides the "downloads" button. The poolname_rewards functions can indeed probably be moved into separate files for easier sharing, along with whatever is in pools.conf presently. Just remember that poolname_rewards is not critical for single miners, since everything necessary for pool hopping is already contained in pools.conf.

Quote from: M4v3R on June 29, 2011, 10:19:26 AM

Quote from: README

To pay users, create a "main" account, move funds to it, and run:
./Multipool.pl save/`ls -t save|head -n1` getpayouts | tee pay
bitcoind sendmany main `cat pay` payout

From what I understand - I have to manually move the funds from all accounts associated to the pools to "main" account, and then execute these commands? Is there any automatic way to do this? And do you use a cron script for running this periodically?

Also, please post your Bitcoin address in the first post so we can donate to you!

I was too hesitant to set the payouts on automatic, since that is the one single step that is irreversible in case of any miscalculations. As it is, there are only two commands to run, with a pause in between to allow you to glance over the numbers to see that they are sensible. And moving btc gold from account to account... builds strength. You can definitely automate all these steps in a cron script if you are more fearless Wink

. Also, I don't beg, and neither did I do this for btc.

Quote from: M4v3R on June 29, 2011, 12:49:59 PM

Unless you have a few GH/s to throw at it, I'd disable the solo pool, as it will not give you profits for weeks and just "waste" GPU cycles

.

You misunderstand: the solo pool isn't there to "waste" your GPU cycles on solo mining, it is there to ensure that you do not waste your GPU cycles. It is probably unlikely that you will run into this problem as a single miner, but there have been times for Multipool when enough pools went down/had insufficient responsiveness that Multipool was unable to pull enough getworks to satisfy all the connected miners. If not for solo shares, those miners would have been idling. Solo shares also mitigate the harm that uncooperative miners can do (see "user_lawful" function). In normal operations, the only time you, as a single miner, will ever receive solo shares is at the very beginning, before multipool has had time to connect to the other pools.