Bitcoin Forum
December 13, 2024, 03:03:44 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Running 2 Miners on the same GPU (for backup purposes)  (Read 1484 times)
PcChip (OP)
Sr. Member
****
Offline Offline

Activity: 418
Merit: 250


View Profile
June 08, 2011, 11:10:15 PM
 #1

I've read posts from several people that say they run multiple miners on each GPU, each connected to a different pool so that if one pool has problems, the hashing power shifts to the pool that is still operational, and they also get a small boost in total hashing power.

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!

Legacy signature from 2011: 
All rates with Phoenix 1.50 / PhatK
5850 - 400 MH/s  |  5850 - 355 MH/s | 5830 - 310 MH/s  |  GTX570 - 115 MH/s | 5770 - 210 MH/s | 5770 - 200 MH/s
rearwheels
Sr. Member
****
Offline Offline

Activity: 444
Merit: 254



View Profile
June 09, 2011, 06:46:28 AM
 #2

I've read posts from several people that say they run multiple miners on each GPU, each connected to a different pool so that if one pool has problems, the hashing power shifts to the pool that is still operational, and they also get a small boost in total hashing power.

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. Cheesy

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").

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!