|
Title: Solitary worker vs. Multiple workers for a given hash rate? Post by: Mousepotato on July 14, 2011, 08:25:44 PM 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.
Title: Re: Solitary worker vs. Multiple workers for a given hash rate? Post by: bcpokey on July 14, 2011, 09:36:50 PM 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. Title: Re: Solitary worker vs. Multiple workers for a given hash rate? Post by: AngelusWebDesign on July 14, 2011, 09:37:48 PM 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. Title: Re: Solitary worker vs. Multiple workers for a given hash rate? Post by: Mousepotato on July 14, 2011, 09:50:29 PM 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. Title: Re: Solitary worker vs. Multiple workers for a given hash rate? Post by: grue on July 14, 2011, 11:00:12 PM 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. 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. |