Flexible mining proxy

[btc_man]

this is what is showing up in the apache logs

Code:

192.168.2.2 - default [03/Jul/2011:10:03:50 -0400] "POST / HTTP/1.1" 401 364 "-" "phoenix/1.4"
192.168.2.2 - default [03/Jul/2011:10:04:00 -0400] "POST / HTTP/1.1" 401 364 "-" "phoenix/1.4"
192.168.2.2 - default [03/Jul/2011:10:04:10 -0400] "POST / HTTP/1.1" 401 364 "-" "phoenix/1.4"
192.168.2.2 - default [03/Jul/2011:10:04:20 -0400] "POST / HTTP/1.1" 401 364 "-" "phoenix/1.4"
192.168.2.2 - default [03/Jul/2011:10:04:30 -0400] "POST / HTTP/1.1" 401 364 "-" "phoenix/1.4"

And this is the command that i am using to launch the miners

Code:

python phoenix.py -u http://192.168.2.7:8337 -k poclbm DEVICE=2 BFI_INT WORKSIZE=128 AGGRESSION=8 FASTLOOP VECTORS

Can you maybe try to tell me what the problem is or what other info i need to figure the problem out?

Response 401 is "unauthorized."  Your command does not appear to include any authentication information.  You need to add the username and password of one of the proxy's worker accounts.

how would I add the username and password in the string, could you give an example. I plan to donate when i get this running. Please and Thank You!

[1714102972]

1714102972

[1714102972]

1714102972

[1714102972]

1714102972

[1714102972]

1714102972

[error]

how would I add the username and password in the string, could you give an example. I plan to donate when i get this running. Please and Thank You!

The username and password go in the URL, just as it says in the main Phoenix miner thread (which is where you really should have gone first). Example: http://username:password@host:port

[Mr2001]

I've patched this proxy to perform automatic pool hopping, directing requests to the most profitable pools, and have been using it successfully for several days on 3 proportional pools (very hoppable), 2 score-based (slightly hoppable), as well as PPS and solo mining as fallbacks. I don't have exact statistics on the earnings yet, but I believe it's over 20% more than I was making before.

I've only shared my patch with one friend, but I'm considering releasing it to the public for a bounty. Would anyone be interested?

[MiningBuddy]

I've patched this proxy to perform automatic pool hopping, directing requests to the most profitable pools, and have been using it successfully for several days on 3 proportional pools (very hoppable), 2 score-based (slightly hoppable), as well as PPS and solo mining as fallbacks. I don't have exact statistics on the earnings yet, but I believe it's over 20% more than I was making before.

I've only shared my patch with one friend, but I'm considering releasing it to the public for a bounty. Would anyone be interested?

No, there are better free & opensource versions already available, thanks.

[Mr2001]

No, there are better free & opensource versions already available, thanks.

Cool, I'd love to see what they do differently. Any besides Multipool?

[Disposition]

I been doing some research into the Long Polling issue, wouldn't be possible to just let the miner connect to the LP address directly instead of going through the proxy?

[cdhowie]

I been doing some research into the Long Polling issue, wouldn't be possible to just let the miner connect to the LP address directly instead of going through the proxy?

No.  The LP request will return work, and if the work doesn't pass through the proxy then it can't be recorded in the database.  And if it can't be recorded in the database, then work submissions against that work cannot be routed to their source pool, and the work the miner has done will have been for nothing.

Further, the LP specification implies that the X-Long-Polling header must return a host-relative URI.  (Though some pools do not follow this.)

[Disposition]

No.  The LP request will return work, and if the work doesn't pass through the proxy then it can't be recorded in the database.  And if it can't be recorded in the database, then work submissions against that work cannot be routed to their source pool, and the work the miner has done will have been for nothing.

I see.

Further, the LP specification implies that the X-Long-Polling header must return a host-relative URI.  (Though some pools do not follow this.)

I thought that was changed, most miners supports full url PL.

[kripz]

How goes the C# backend?

[cdhowie]

How goes the C# backend?

I've run into a few bugs and have been fixing them and doing a lot of testing.  It's getting there quickly.

[callmeivan]

I used xampp 1.7.4 to set it up but after a couple of minutes (after adding some workers) i get an error.

Until then everything works, does somebody know how to fix it ?

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[08004] [1040] Too many connections' in /opt/lampp/htdocs/common.inc.php:33 Stack trace: #0 /opt/lampp/htdocs/common.inc.php(33): PDO->__construct('mysql:host=loca...', 'user', 'password') #1 /opt/lampp/htdocs/admin/pool.php(31): db_connect() #2 [internal function]: AdminPoolController->indexGetView() #3 /opt/lampp/htdocs/mvc.inc.php(142): ReflectionMethod->invoke(Object(AdminPoolController)) #4 /opt/lampp/htdocs/mvc.inc.php(178): Controller->execute() #5 /opt/lampp/htdocs/admin/pool.php(140): MvcEngine::run(Object(AdminPoolController)) #6 {main} thrown in /opt/lampp/htdocs/common.inc.php on line 33

[nux]

I'm using the latest version of the proxy software, and the latest poclbm.  Since updating to the more verbose poclbm (week or two ago) I see this error all the time:

proxy.hostname.net:80 Problems communicating with bitcoin RPC 0 2

Then it recovers from 0mhash/s and looks like this

proxy.hostname.net:80 93870 khash/sunicating with bitcoin RPC 0 2

until it gets back up to the normal speed (which takes just a second or so).

I see this happen every few seconds give or take.  Has anyone else seen issues like this?  Since the last week or so I've had to stop using this awesome software as that error slows down my hashing.

Thanks

Edit: I'm running Apache on Debian.  Server is tuned to handle a lot of load, and is nowhere near capacity.  I'm not finding any issues in the error_log files and not sure how I can debug further at this point.

[geek-trader]

Multipool is currently down, so I haven't been able to review the problem and proposed fix.

He's put the code on Github, so someone else set up a server here: http://multiclone.us.to:18080/ (mining port 18337).
It has the same problem.

http://forum.bitcoin.org/index.php?topic=17970.msg302834#msg302834

Do these comments mean this project doesn't work with Multiclone.us.to  ?  Because otherwise, this looks awesome.

[cdhowie]

Do these comments mean this project doesn't work with Multiclone.us.to  ?  Because otherwise, this looks awesome.

Looking at the getwork response from Multiclone, I see no reason why it should not work with my proxy.

[nux]

Anyone else having this issue?  I tried a fresh install of the proxy and still having the problem.

This only started after upgrading to  the latest poclbm.

Here's my output:

proxy.hostname.net:80 11/07/2011 11:31:01, Setting pool g11 @ proxy.hostname.net:80
                                                                                proxy.hostname.net:80 11/07/2011 11:31:02, Using new LP URL /index.php/1/aHR0cDovL3VzZWFzdC5idGNndWlsZC5jb206ODMzMi9MUA%3D%3D
proxy.hostname.net:80 11/07/2011 11:31:02, LP connected to proxy.hostname.net:80
proxy.hostname.net:80 229016 khash/snicating with bitcoin RPC 0 2
proxy.hostname.net:80 229331 khash/snicating with bitcoin RPC 0 2
proxy.hostname.net:80 11/07/2011 11:32:15, 02463d19, accepted 0 2
proxy.hostname.net:80 Problems communicating with bitcoin RPC 0 2
proxy.hostname.net:80 11/07/2011 11:32:34, c30efce9, accepted 0 2
proxy.hostname.net:80 228730 khash/snicating with bitcoin RPC 0 2
proxy.hostname.net:80 11/07/2011 11:33:56, 1888d04e, accepted 0 2
proxy.hostname.net:80 11/07/2011 11:34:42, 92512293, accepted 0 2
proxy.hostname.net:80 215716 khash/snicating with bitcoin RPC 0 2

I'm using the latest version of the proxy software, and the latest poclbm.  Since updating to the more verbose poclbm (week or two ago) I see this error all the time:

proxy.hostname.net:80 Problems communicating with bitcoin RPC 0 2

Then it recovers from 0mhash/s and looks like this

proxy.hostname.net:80 93870 khash/sunicating with bitcoin RPC 0 2

until it gets back up to the normal speed (which takes just a second or so).

I see this happen every few seconds give or take.  Has anyone else seen issues like this?  Since the last week or so I've had to stop using this awesome software as that error slows down my hashing.

Thanks

Edit: I'm running Apache on Debian.  Server is tuned to handle a lot of load, and is nowhere near capacity.  I'm not finding any issues in the error_log files and not sure how I can debug further at this point.

[nux]

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.

[cdhowie]

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.

[nux]

One feature I thought would be handy is something like a worker group.

Essentially a way to mass manage a handful of workers.  For example, create a pool, and update 9 workers at once to all use it with the same login, password, priority etc.

I currently just use SQL to do it manually.  Add a worker_id/pool_id combo manually, and then an UPDATE .. WHERE pool_id = to add a pool to every one of those workers.

[NickW]

I'm running this fine (so far) with nginx + php-fpm as the webserver.

One thing to note to get LP working is to set fastcgi_read_timeout in the nginx virtual host to something high (such as 3600) along with max_execution_time in the php.ini file.

You also need some fairly specific settings to get the php parameters such as path_info passed along correctly. This is what I have.

Code:

location ~ ^(.+\.php)(.*)$ {
  root    /web/root/here;

  fastcgi_index index.php;
  fastcgi_split_path_info ^(.+\.php)(.*)$;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param PATH_INFO  $fastcgi_path_info;
  fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
  fastcgi_read_timeout 3600;
  fastcgi_pass    127.0.0.1:9000;
  include fastcgi_params;

}

[kripz]

Everytime a block is solved i get this after long poll event:

[2011-07-12 22:22:02] JSON-RPC call failed: {
   "code": 0,
   "message": "No enabled pools responded to the work request."
}