Topic: Flexible mining proxy - page 8. (Read 88735 times)

yeah I think I'm going to set up a POC pool on a VM for personal use and play around.

After 3 days soloing namecoin with 2GH and not finding a single block I don't plan on doing that again anyways... Wouldn't be so bitter if I hadn't found 23 blocks in the week before (half at ~3k difficulty) for BitParking

There is indeed, it's called pushpool.  But it's a real PITA to build.  Once you have it going, it'll log shares to a text file, which you can use to dig out the info you want/need.  You can also make it log shares to the database backend (SQLite, MySQL etc).

I had problems with this once i connected 4 machines to it (6 total miners).

Tried it soloing and on bitparking and while I slept and found that I wasn't getting what I was supposed to.

turned off both namecoin options and was hitting slush and deepbit and getting about 2/3 of the shares I should have

connections to the proxy started timing out, so restarting apache fixed it, but i didn't trust it enough to keep going

This was on a VM w/ 1GB of ram

What kind of hardware are you guys running on?

Testing out now, looks fairly solid.

What sort of values can i set for 'average_interval'? and what effects will it have?

Also, please add rejected per hour and efficiency.

Edit: I get alot of miner idle using this...

Really wish there was a way to monitor anything on solo mining besides getwork w/ the proxy

All working "quite" well with 1 miner and 1 pool.

Some things i've noticed:

• I have a lot of "Listener for "Proxy": 15/06/2011 00:23:30, Unexpected error:" lines on GUIMiner's console, using poclbm and the proxy.
• Long polls seem to get through sometimes, but not all the time - i get a lot more of these when connecting to the pool directly, but maybe this was random.
• Fall back to other pools does not work for me, nor will the miner work on any other pool than the first one i created, even if i disable that pool overall or remove it from the worker's list.
• A second worker i added is able to get work (only from the first pool i defined as well), but the returned shares never show up anywhere - not on the dashboard nor the pool's stats page. "Last accepted submission" is "Never" for that worker all the time as well.

I'll dig into the problem further, but have no time to do so yet.
Besides that: Good work and keep it up! When i'll have more than some fractions of BC, i'll donate to you.

Update:
Long poll seem to be okay.
Problem 3 was solved by adding 'http://' to the pool's url. Won't work without.

There should be a way to copy worker/pool configs

so instead of setting up 10x pools on 10x workers you can set it up once then copy it to the rest, then go in and change the logins as necessary.  Or a way to use a variable in the config so you build X workers with the suffix X changed on each one

Cool got it working on a Centos 5.6 VM w/ 5.3.6

had a bit of difficulty getting PDO installed but it went ok.

looking forward to getting this working!

5.3 at least.

Do you want patches?  I'm testing putting 50 miners through this proxy and was running into stability issues.  I have mysql on a separate machine and am used to that being a bottleneck, so I looked into making it use persistent connections.  I am not familiar with the PDO extension, but found the instantiator in common.inc.php on line 31; I added array(PDO::ATTR_PERSISTENT => true) to the new call and this took care of my problems.

The whole line now looks like this:

return new PDO($BTC_PROXY['db_connection_string'], $BTC_PROXY['db_user'], $BTC_PROXY['db_password'], array(PDO::ATTR_PERSISTENT => true) );

I now have 32 connections from the proxy web server staying open (which is what I want).

Hopefully this helps someone.

4.4.8

5.x required?

Which version of PHP?  It's possible that your version does not support function access modifiers.

Parse error: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in /home/REDACTED/public_html/admin/index.php on line 28

Hmm, not sure why i'm getting this.  This is on the admin page.  It complains about line 125 on the root

Has anyone got this working with Lighttpd (under Gentoo)? I am trying to rule out wider system-level errors before digging deeper into this code. Basically, my clients (Phoenix) are connecting to the proxy, but they are not getting any work. My PHP setup should be OK as I use it for other web content, and the admin interface seems to work fine. I have set this up in a separate port so there are no subdirectory issues for clients.

Sounds like the MySQL database got corrupted.  Which is weird, since table logs are supposed to keep that from happening.  :/

Rebooted after crash and now Worker Status table on main dashboard is completely blank.  Recent work submissions and recent failed submissions still show up just fine in the top 2 tables, but the bottom table is blank.

Any ideas?

Edit:  I was also having connection issues.  I exported my workers and pools settings.  Imported the original schema back, and imported those saved settings.  All is well now.

That's weird.    The code path isn't any different if you have one or more pools configured...

If any of you are still having stale share issues, would you mind taking a capture of the network traffic?  On the proxy host, issue this as root:


Then email me the proxy.pcap file after an hour or two.  Note that this file will contain all of the traffic on these ports and this means that I will have access to your proxy worker passwords as well as your pool worker passwords.  You may certainly encrypt the file to my GPG key if you are worried about the file being intercepted.  (Specifically, note that if you talk to a bitcoind from the web server, this will expose your RPC password!  So be especially careful in this case.  I'm not going to misuse this information, but... well, if I were you, I wouldn't trust me blindly either. )

If possible, capture traffic from the workers to the pools directly, without the proxy, and email me that as a separate file.  Comparing the two files will help me determine what's going on.

Even better, if you're using a pool supporting long-polling, have one miner going through the proxy and at the same time another one not using the proxy, and mail me both files.  Seeing how the long-polling requests return in both cases (they should be identical...) will help me diagnose this.

Thanks all for the feedback, donations, and support!  It's heartening to know that the software is fulfilling its purpose and that people find it helpful. 

If you aren't using /var/lib/php5 for your session files, do "php -i | grep session.save_path" on the command line, or make a file with:


In your document tree, and load it in your browser, then look for session.save_path.

An alternative removal method is:

Thanks for the report.  This was indeed a bug, and has been fixed in master.