This sounded like a win-win situation for me, so I opened a connection to deepbit on both my GPU's as a backup if BTCGuild has more problems; after adding the two rates together it did indeed seem like there was little boost in total hashing power.
However, using btc-poolwatch.com I noticed lower total rates. Like, instead of ~800 MH/s it would report ~550 MH/s. I know they're estimates and they fluctuate, but it was just much lower than normal (especially considering the programs were reporting a slightly higher hashing rate)
Anyone have any experience with this method, or any ideas as to what the issue was in my situation?
Thanks!
Hi,
The results from the JSON API calls are usually cached, and tends to be slightly stale. This is to reduce the loads on the pool's servers.
e.g. At btcguild.com, when I refresh my accounts page, the hashrate will keep changing. But not at the JSON API page.
Thus the information at www.btc-poolwatch.com (which pulls the data via the JSON API) is really a snapshot rather than for statistical comparison.
One thing that seems to be consistent across the pools is that the hashrate reported at the pools are lower than what you see at your client. The pools typically average the hashrate (up to 30mins, AFAIK). While the client will display the hashrate per second (phoenix is configurable to average this out as well). And of course, when we stare at the client, we take note of the highest hashrate, but not the lowests.
What I've done for 1 rig:
5870: -d1 -btcguild -f 5 (main display)
5870: -d1 -btcmine -f 50
5970a: -d2 -btcguild -f 1
5970a: -d2 -btcmine -f 50
5970b: -d3 -btcmine -f 1
5970b: -d3 -btcguild -f 50
So 3 GPUs runs on 6 processes.
Once a GPU goes to "idle", the secondary process picks up the slack and hash rate goes from 4/500mh/s to 3/400,000mh/s.
We'll see how this goes, but I don't think I can give any good numbers on how well this works, as my rigs are connected via 3G and sometimes ping to google.com is over 11s (yes, without the "m").