Bitcoin Forum
May 28, 2024, 02:03:00 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Solitary worker vs. Multiple workers for a given hash rate?  (Read 1245 times)
Mousepotato (OP)
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000


Seal Cub Clubbing Club


View Profile
July 14, 2011, 08:25:44 PM
 #1

Is there any advantage to generating shares if you split up your bandwidth among multiple workers for a given pool with a set hash rate?  Can a single worker be split between multiple GPUs?  I guess I could simply try the latter out on my own, but I'd have to wait til I get home.

Mousepotato
bcpokey
Hero Member
*****
Offline Offline

Activity: 602
Merit: 500



View Profile
July 14, 2011, 09:36:50 PM
 #2

Not sure what your question is. A hash is a hash is a hash. For pools? There is no advantage to having the same card generate multiple work threads, except that some people suggest that you might squeeze a couple extra Hashes out of the parallelized GPGPU structure. I don't really see it myself.

As for a single worker being split between multiple GPUs, again not sure exactly what you're asking, but I have a single worker designated for each of my boxes because I am lazy, rather than per card on each pool I use. So if that is what you are asking then yes it's fine. There is no difference between a single worker or multiple workers on the pools side.
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
July 14, 2011, 09:37:48 PM
 #3

That's like saying "should I roll 4 dice all at once, or 2 dice over here and 2 dice over there?"

It's all random luck, so your results should be the same.
Mousepotato (OP)
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000


Seal Cub Clubbing Club


View Profile
July 14, 2011, 09:50:29 PM
 #4

Not sure what your question is. A hash is a hash is a hash. For pools? There is no advantage to having the same card generate multiple work threads, except that some people suggest that you might squeeze a couple extra Hashes out of the parallelized GPGPU structure. I don't really see it myself.

Yes, this was essentially what I was wondering.  Over the long haul it wouldn't really matter I supposed, but on the 0-minute "lucky" block solves where a multi-GH/s worker might only contribute a dozen or so shares before the block is solved, it could make a significant difference if indeed splitting the hashing power up into 2 or more workers makes a diff.

Mousepotato
grue
Legendary
*
Offline Offline

Activity: 2058
Merit: 1431



View Profile
July 14, 2011, 11:00:12 PM
 #5

Not sure what your question is. A hash is a hash is a hash. For pools? There is no advantage to having the same card generate multiple work threads, except that some people suggest that you might squeeze a couple extra Hashes out of the parallelized GPGPU structure. I don't really see it myself.

Yes, this was essentially what I was wondering.  Over the long haul it wouldn't really matter I supposed, but on the 0-minute "lucky" block solves where a multi-GH/s worker might only contribute a dozen or so shares before the block is solved, it could make a significant difference if indeed splitting the hashing power up into 2 or more workers makes a diff.
lol?
That's like saying "should I roll 4 dice all at once, or 2 dice over here and 2 dice over there?"

It's all random luck, so your results should be the same.


It is pitch black. You are likely to be eaten by a grue.

Adblock for annoying signature ads | Enhanced Merit UI
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!