Flexible mining proxy

[shotgun]

I have the same problems as alfalfa. Every so often apache runs out of clients and has to be restarted. Increasing the clients doesn't help because then PHP throws the exception. I run 4 separate miners through the proxy and use the latest phoenix release. I mine mostly on Eligius.

It looks like new connections keep being opened without closing the old ones (or maybe it closes the old ones slower then it opens the new ones) Sometimes it recovers on its own.

This is likely due to a bug in the application where it's not closing connections properly. Simple solution: create a /etc/crontab entry that restarts apache and/or mysql every N hours.

Code:

01 * * * * root /etc/init.d/httpd restart > /dev/null
02 * * * * root /etc/init.d/mysqld restart > /dev/null

[bitfoo]

After watching tshark, poclbm.py output, and tailing the access log for the proxy, I have determined that a low KeepAliveTimeout setting in the Apache config was the culprit.

The KeepAliveTimeout on my server was 3 seconds, and the ask rate was 5.  This caused the miner to try to use a KeepAlive session, only to find it timed out.  Then it had to establish a new connection.  This was giving the connection issues I was seeing.

Essentially what this means is the KeepAliveTimeout setting has to be higher than the ask rate.  I would suggest adding a few seconds on top to make sure there's a little wiggle room.

Thanks for the info!  I'll add this to the readme, and perhaps to the .htaccess file.

In general, is it preferable to configure Apache with KeepAlive enabled or disabled for this proxy?

[shotgun]

After watching tshark, poclbm.py output, and tailing the access log for the proxy, I have determined that a low KeepAliveTimeout setting in the Apache config was the culprit.

The KeepAliveTimeout on my server was 3 seconds, and the ask rate was 5.  This caused the miner to try to use a KeepAlive session, only to find it timed out.  Then it had to establish a new connection.  This was giving the connection issues I was seeing.

Essentially what this means is the KeepAliveTimeout setting has to be higher than the ask rate.  I would suggest adding a few seconds on top to make sure there's a little wiggle room.

Thanks for the info!  I'll add this to the readme, and perhaps to the .htaccess file.

In general, is it preferable to configure Apache with KeepAlive enabled or disabled for this proxy?

enabled afaik, ymmv

[Intention]

So I got this up and running on just a temporary vps before I commit to running this on a local machine since I'm very bad at these things and things usually end up getting reinstalled.

I have the web portion up and running with the dashboard etc it is currently installed in the root of the machine's apache directory.  I have pointed my miner to the ip of my vps however I keep getting the same loop of errors.

2011-09-02 05:36:39: Listener for "test": myip:8332 02/09/2011 05:36:39, Problems communicating with bitcoin RPC 1 2
2011-09-02 05:36:44: Listener for "test": myip:8332 02/09/2011 05:36:44, Problems communicating with bitcoin RPC 2 2
2011-09-02 05:36:49: Listener for "test": myip:8332 02/09/2011 05:36:49, Problems communicating with bitcoin RPC 3 2
2011-09-02 05:36:49: Listener for "test": myip:8332 02/09/2011 05:36:49, No more backup pools left. Using primary and starting over.

I have made sure magic_quotes_gpc is off by manually entering the option and I've also changed the keepalive time out to 10 seconds however I am not sure what else could be causing this.

[skEwb]

Ran it on my own private VPS for a while and had no issues with it. It was working as it should. Thanks for the proxy.

[kripz]

This is long dead, though still working. I've read reports on this proxy loosing up to 10% of shares due to the code and/or apache not keeping up with the number of requests.

Please check your miner/proxy/pool stats and compare.

[coblee]

This is long dead, though still working. I've read reports on this proxy loosing up to 10% of shares due to the code and/or apache not keeping up with the number of requests.

Please check your miner/proxy/pool stats and compare.

I've seen it slow down due to db getting too large. So I have to clean them out at least once a week doing this:

DELETE FROM `work_data` WHERE DATEDIFF(UTC_TIMESTAMP(), `time_requested`) > 0;
DELETE FROM `submitted_work` WHERE DATEDIFF(UTC_TIMESTAMP(), `time`) > 0;

[Cdecker]

The proxy is quite good AFAIK, I have a consistent rejection rate of ~1%, but that's to be expected.

[Naven]

@cdhowie, are u planing any updates?

[btc_artist]

Watching

[siggy]

apologies for resurecting an old thread..

is this still being updated / mantained?  Is there a better mining proxy out there?   I've now got 6 rigs I'm managing, and soon to be expanding further... having one central location to view stats & manage pools would be a godsend...

thanks,
Sigg

[fizzisist]

apologies for resurecting an old thread..

is this still being updated / mantained?  Is there a better mining proxy out there?   I've now got 6 rigs I'm managing, and soon to be expanding further... having one central location to view stats & manage pools would be a godsend...

thanks,
Sigg

I use this proxy and it works well enough for me. It's a shame that it's not still actively developed, though.

I took a look at the various forks on Github and it looks like virtualcodewarrior's is the most recently updated, but the last commit was Aug 21, 2011... Still, it might be worth a look (I haven't looked at it yet).

I second the question, is there a better proxy out there? Should we start a bounty or something? Are there any major problems with the proxy that need fixing?

[ummas]

I`m on the topic now.
I`ll try to run that, and if it will work for me, i`ll start thinking for better solution.
Is there any other as fizzisist said ?

[Red Emerald]

apologies for resurecting an old thread..

is this still being updated / mantained?  Is there a better mining proxy out there?   I've now got 6 rigs I'm managing, and soon to be expanding further... having one central location to view stats & manage pools would be a godsend...

thanks,
Sigg

I use this proxy and it works well enough for me. It's a shame that it's not still actively developed, though.

I took a look at the various forks on Github and it looks like virtualcodewarrior's is the most recently updated, but the last commit was Aug 21, 2011... Still, it might be worth a look (I haven't looked at it yet).

I second the question, is there a better proxy out there? Should we start a bounty or something? Are there any major problems with the proxy that need fixing?

Any progress on this?

[Lomax42]

Does anyone can tell what's the problem?? Why do so many Getworks * and so little Shares *
Pool              Latest work requested                                Getworks * Shares * Rejected *  
Deepbit By 123 at 2012-06-14 06:10:56 UTC                         7939         1936        1.86%


Use cgminer-2.3.4-win32 & 15 comp

[MasterX]

Thanks for the release!  I'll dedicate some time to pulling and installing it tomorrow, and pass that money along once it's up.  After all, a promise is a promise  Thanks again.

Cool, thanks!  Hope the software works for you.

If you run into any trouble, let me know.  I intend to support the software I publish.  (That goes for everyone.)

Hi cdhowie,

Maybe i'm missing something, but after i installed the database and changed mysql parameters (login&passwd);
When typing the url in my browser http://127.0.0.1 i get the apache login window, askin for credentials, but whatever i try, it keeps coming back and i'm unable to login.
I tried changing the credentials in the config file, but even with default 'admin' + 'changeme' it does not work.

Is there anything else i should check or do before i'm able to login/use this software?

Any help would be great!

PS: i'm testing this on the most recent stable release of Xampp.

[Baazee]

I use this software on my server.
I am actually very happy with it, but have the problem that more and more pools switch to stratum.
Is there an update?