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?
Topic: Flexible mining proxy (Read 88588 times)
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.
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.)
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.
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
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
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
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?
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 ?
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 ?
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
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?
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
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
Watching
@cdhowie, are u planing any updates?
The proxy is quite good AFAIK, I have a consistent rejection rate of ~1%, but that's to be expected.
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.
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;
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.
Please check your miner/proxy/pool stats and compare.
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.
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.
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.
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.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.
In general, is it preferable to configure Apache with KeepAlive enabled or disabled for this proxy?
enabled afaik, ymmv
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.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.
In general, is it preferable to configure Apache with KeepAlive enabled or disabled for this proxy?
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.
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
02 * * * * root /etc/init.d/mysqld restart > /dev/null
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.
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.
Of course, fix a problem and another shows up
Code:
Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [1040] Too many connections' in
/var/www/common.inc.php:33\nStack trace:\n#0 /var/www/common.inc.php(33): PDO->__construct('mysql:host=loca...', 'Alphy',
'bitminer')\n#1 /var/www/index.php(31): db_connect()\n#2 {main}\n thrown in /var/www/common.inc.php on line 33
Open the /etc/mysql/my.cnf (debian) or /etc/my.cnf (rhel) and set max_connections=250 or to something higher than what you have currently. I'm not going to get into the per-thread buffer memory usage stuff when you increase max_connections... so either read up on it or just be aware that each connection allocates ram so if you are low on memory you might want to consider that impact. The default mysql max_connections is 100, fyi. I am not sure why flexible proxy uses connections so much - maybe it's not making persistent or pooled connections.
Of course, fix a problem and another shows up
Code:
Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [1040] Too many connections' in
/var/www/common.inc.php:33\nStack trace:\n#0 /var/www/common.inc.php(33): PDO->__construct('mysql:host=loca...', 'Alphy',
'bitminer')\n#1 /var/www/index.php(31): db_connect()\n#2 {main}\n thrown in /var/www/common.inc.php on line 33
Jump to: