Just pushed some updates.

Applied patch from cdecker implementing hash speed estimation for workers (issue 5).
Implemented timezone conversion (issue 7).

These changes require modifications to your config.inc.php. If you pull without updating your config.inc.php, the software will break.

To address some posts:

Quote from: BurningToad on May 17, 2011, 11:27:00 AM

Actually this just didn't work very well for me Sad

Set it up with BTC Guild as primary and Slush as secondary. BTC Guild is having intermittent connection issues, so I wanted a backup. However, overnight all of my GUIMiner clients got stuck with a "connection problem". My one phoenix client (which is also on same machine as my proxy) continued working fine however.

Some miners will bail on a connection if it doesn't return work within 3-5 seconds. This is not always enough time for the proxy to detect a fail condition, and so the miner gives up before the proxy has a chance to try another pool.

Quote from: leepfrog on May 23, 2011, 04:22:25 AM

Actually this did not run as well as expected. I've got a very high rate of rejected (about 10%) and after running for two hours phoenix stalled again:

I have started seeing similar problems on my install. This is being actively researched.

Quote from: ewal on May 26, 2011, 06:38:51 AM

I did see an occasional LP message, but not frequently enough as compared to blocks being found in the network. I also regularly got errors about "NoneType" not being indexable.

I have been seeing the same with poclbm lately. I'm not sure what changed to make this happen, but I suspect it is related to the stale shares problem.

Quote from: oVPN on May 23, 2011, 10:43:54 AM

i believe ufa cpu-miner is not supported at the moment? all my tests ran in timeouts Sad

I haven't used that particular miner and so I'm not sure if the proxy supports it. If the miner isn't doing anything too wacky it should work... If I get some free time I might investigate this.

Quote from: ewal on May 26, 2011, 06:38:51 AM

long polling does not seem to work with phoenix through the proxy but works fine when connected directly.

There are some issues with long polling that are not easily addressed by the current model. Long polling should in theory work just fine if your preferred pool doesn't go down, but during a failover scenario it can get a little bit wonky. Some miners behave differently with respect to how they handle changing long-polling URLs, and so this is something that will take a lot of engineering to fix.

In the meantime I may supply a config option to disable long polling entirely; broken long polling is worse than none at all.

Quote from: ewal on May 26, 2011, 06:38:51 AM

phoenix miner *hammers* the web server with requests to index.php. Something like 10-20 requests per second as seen in the apache access.log. When connected directly and observed with tcpdump it behaves much more normally (1 request every 5 seconds or so).

Sounds like a bug in Phoenix. Can you take some sniffs of this behavior with tcpdump -w bmp.pcap port 80 and email me the pcap file(s)? This will help me figure out what's going on. (Please compress them, and you can optionally encrypt them to my GPG key. This should not expose your mining account passwords, only your local proxy worker and possibly admin passwords.)

Quote from: datathe1st on May 26, 2011, 08:34:16 AM

Btw if I have access to computers at school and they are behind a firewall and so cannot mine, can I use this software to get around that?

As long as the computers can make outbound connections on whatever port you are running your web server on, yes. Transparent (or non-transparent) HTTP proxies should be able to process these requests too, though they might strip long-polling info.