Topic: If I am mining with 2 GPUs at the same time, but have a few problems... (Read 2820 times)
April 08, 2011, 01:56:33 AM
You can just swap your monitor to it. I think that a card is activated and the miner is running you don't have to it plugged anymore for it keep going.
April 07, 2011, 05:36:22 PM
2nd GPU does not mine without Crossfire 
Do you have it activated in windows? Meaning, a monitor (or dummy plug) connected providing resistance so that windows activates it.
yea that makes sense, like for folding right? I'd have to get some stuff from a shop nearby though.
Could connecting both to the same monitor work? (1 DVI other HDMI)
Yep.
I'm not sure, but it's worth a shot.
April 07, 2011, 05:35:38 PM
2nd GPU does not mine without Crossfire
Do you have it activated in windows? Meaning, a monitor (or dummy plug) connected providing resistance so that windows activates it.
yea that makes sense, like for folding right? I'd have to get some stuff from a shop nearby though.
Could connecting both to the same monitor work? (1 DVI other HDMI)
April 07, 2011, 05:23:38 PM
2nd GPU does not mine without Crossfire
Do you have it activated in windows? Meaning, a monitor (or dummy plug) connected providing resistance so that windows activates it.
April 07, 2011, 02:12:25 PM
2nd GPU does not mine without Crossfire
April 07, 2011, 01:35:20 PM
You have to ask 
Windows 7 Pro X64, both are 6870s. 1st is a Reference Visiontek, 2ns is the XFX Black Edition (940 core 1150 mem stock). Yes Crossfired. GPU load dips juuuuust a little when the Mh/s dips. Since I set them to -f 120 to lower the dip, th 1st is a dead 98% constant, while the 2nd varies between 96 and 98, but stays at 97 most of the time.
Thanks in advance for the help
Windows 7 Pro X64, both are 6870s. 1st is a Reference Visiontek, 2ns is the XFX Black Edition (940 core 1150 mem stock). Yes Crossfired. GPU load dips juuuuust a little when the Mh/s dips. Since I set them to -f 120 to lower the dip, th 1st is a dead 98% constant, while the 2nd varies between 96 and 98, but stays at 97 most of the time.
Thanks in advance for the help
I know of someone who had a somehow similar problem: with crossfired card, the slave card wouldn't run at 99% load on -f1, but fluctuate instead. Taking off the crossfire bridge and running the 2nd card independently fixed it. I guess you could try and test both your cards running at -f1. If the slave won't run at max load then you know where the problem is coming from.
Thanks I'll try that in 5 mins.... I do not think I should take it out/ put it in hile the comp is running so every time I wanna game I have to restart my PC?
Oh wellYou don't "have" to take it out. As long as you know where the problem comes from and that your hardware isn't exposed to some sort of risk, you can then choose between better gaming or better mining.
April 07, 2011, 12:45:49 PM
You have to ask
Windows 7 Pro X64, both are 6870s. 1st is a Reference Visiontek, 2ns is the XFX Black Edition (940 core 1150 mem stock). Yes Crossfired. GPU load dips juuuuust a little when the Mh/s dips. Since I set them to -f 120 to lower the dip, th 1st is a dead 98% constant, while the 2nd varies between 96 and 98, but stays at 97 most of the time.
Thanks in advance for the help
Windows 7 Pro X64, both are 6870s. 1st is a Reference Visiontek, 2ns is the XFX Black Edition (940 core 1150 mem stock). Yes Crossfired. GPU load dips juuuuust a little when the Mh/s dips. Since I set them to -f 120 to lower the dip, th 1st is a dead 98% constant, while the 2nd varies between 96 and 98, but stays at 97 most of the time.
Thanks in advance for the help
I know of someone who had a somehow similar problem: with crossfired card, the slave card wouldn't run at 99% load on -f1, but fluctuate instead. Taking off the crossfire bridge and running the 2nd card independently fixed it. I guess you could try and test both your cards running at -f1. If the slave won't run at max load then you know where the problem is coming from.
Thanks I'll try that in 5 mins.... I do not think I should take it out/ put it in hile the comp is running so every time I wanna game I have to restart my PC?
Oh well April 07, 2011, 12:21:22 PM
You have to ask
Windows 7 Pro X64, both are 6870s. 1st is a Reference Visiontek, 2ns is the XFX Black Edition (940 core 1150 mem stock). Yes Crossfired. GPU load dips juuuuust a little when the Mh/s dips. Since I set them to -f 120 to lower the dip, th 1st is a dead 98% constant, while the 2nd varies between 96 and 98, but stays at 97 most of the time.
Thanks in advance for the help
Windows 7 Pro X64, both are 6870s. 1st is a Reference Visiontek, 2ns is the XFX Black Edition (940 core 1150 mem stock). Yes Crossfired. GPU load dips juuuuust a little when the Mh/s dips. Since I set them to -f 120 to lower the dip, th 1st is a dead 98% constant, while the 2nd varies between 96 and 98, but stays at 97 most of the time.
Thanks in advance for the help
I know of someone who had a somehow similar problem: with crossfired card, the slave card wouldn't run at 99% load on -f1, but fluctuate instead. Taking off the crossfire bridge and running the 2nd card independently fixed it. I guess you could try and test both your cards running at -f1. If the slave won't run at max load then you know where the problem is coming from.
April 07, 2011, 12:14:09 PM
You have to ask
Windows 7 Pro X64, both are 6870s. 1st is a Reference Visiontek, 2ns is the XFX Black Edition (940 core 1150 mem stock). Yes Crossfired. GPU load dips juuuuust a little when the Mh/s dips. Since I set them to -f 120 to lower the dip, th 1st is a dead 98% constant, while the 2nd varies between 96 and 98, but stays at 97 most of the time.
Thanks in advance for the help
Windows 7 Pro X64, both are 6870s. 1st is a Reference Visiontek, 2ns is the XFX Black Edition (940 core 1150 mem stock). Yes Crossfired. GPU load dips juuuuust a little when the Mh/s dips. Since I set them to -f 120 to lower the dip, th 1st is a dead 98% constant, while the 2nd varies between 96 and 98, but stays at 97 most of the time.
Thanks in advance for the help
April 07, 2011, 04:53:01 AM
Thanks for the clarifications and explaining guys.... Now we can focus on my multi GPU problems? 
well give us details then. What OS are you on, what are the cards, are they crossfired, what are your gpu loads on both?
April 06, 2011, 09:14:10 PM
I'm sorry, but are you agreeing with me in opposition?
If I'm wrong, correct me. But make sure that you know what I'm talking about first, 'kay?
If I'm wrong, correct me. But make sure that you know what I'm talking about first, 'kay?
I was confused by your wording. I thought you were saying that bitcoind did not support more than one client calling GetWork(), and that in order mine with two cores on the same machine, you would have to run two instances of bitcoind or run pool software.
April 06, 2011, 07:18:32 PM
That's correct, GetWork implies that you are using a pool miner, not an independent client.
What? GetWork() is a JSON-RPC call: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
If one GPU can call a local bitcoind for GetWork(), why not more than one? Are two cores at 25 mhash/s each not the same as one core at 50 mhash/s? GetWork already has to return unique work no matter how little time in between calls, no?
I'm sorry, but are you agreeing with me in opposition?
If I'm wrong, correct me. But make sure that you know what I'm talking about first, 'kay?
April 06, 2011, 06:40:23 PM
That's correct, GetWork implies that you are using a pool miner, not an independent client.
What? GetWork() is a JSON-RPC call: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
If one GPU can call a local bitcoind for GetWork(), why not more than one? Are two cores at 25 mhash/s each not the same as one core at 50 mhash/s? GetWork already has to return unique work no matter how little time in between calls, no?
April 06, 2011, 06:11:43 PM
Thanks for the clarifications and explaining guys.... Now we can focus on my multi GPU problems?
April 06, 2011, 06:04:25 PM
If you are mining locally, are you using two independent instances of the mining client? If yes, then it's very unlikely that they are duplicating work.
Would that be necessary? I was under the impression that GetWork() returns unique work.
That's correct, GetWork implies that you are using a pool miner, not an independent client. So if you are successfully mining with a pool, you are not in control of the nonce anyway.
EDIT: And yes, you can use a pair of pool miners to mine independently on your own machine, if you also have a client that is running that is modified to manage pool miners. Either way, pool miners are probably the best route with a machine with multiple GPU's
April 06, 2011, 05:53:33 PM
If you are mining locally, are you using two independent instances of the mining client? If yes, then it's very unlikely that they are duplicating work.
Would that be necessary? I was under the impression that GetWork() returns unique work.
April 06, 2011, 05:49:06 PM
are they?
Not unless your starting nonce is identical. If you are using a pool miner, the pool should be managing the nonces of the miners so that they are not duplicating work, although I'm not certain that this is done.
If you are mining locally, are you using two independent instances of the mining client? If yes, then it's very unlikely that they are duplicating work.
April 06, 2011, 02:22:59 PM
I don't have a dual GPU setup, so I'm going to have to leave that to somebody else.
April 06, 2011, 02:19:46 PM
Every miner is competing with every other miner to find the correct hash for the block. However, it's less like a direct competition as a race. Both are trying to get to the finish line first. Sometimes one will, and sometimes the other will. However, since you're the manager of both competitors, you get paid no matter which one wins.
As to the pool question, since everything is probability and luck with mining, dividing your miners between pools or keeping them on one pool really doesn't matter. Go solo, divide them up, put them on the same pool - over the long haul it will even out. In a bigger pool you will get smaller, more frequent payouts. In a smaller pool, you will get bigger, less frequent payouts. Solo you will get rare, big payouts.
As to the pool question, since everything is probability and luck with mining, dividing your miners between pools or keeping them on one pool really doesn't matter. Go solo, divide them up, put them on the same pool - over the long haul it will even out. In a bigger pool you will get smaller, more frequent payouts. In a smaller pool, you will get bigger, less frequent payouts. Solo you will get rare, big payouts.
Thanks... That's what I figured.
How about the other problems?
April 06, 2011, 02:17:19 PM
Every miner is competing with every other miner to find the correct hash for the block. However, it's less like a direct competition as a race. Both are trying to get to the finish line first. Sometimes one will, and sometimes the other will. However, since you're the manager of both competitors, you get paid no matter which one wins.
As to the pool question, since everything is probability and luck with mining, dividing your miners between pools or keeping them on one pool really doesn't matter. Go solo, divide them up, put them on the same pool - over the long haul it will even out. In a bigger pool you will get smaller, more frequent payouts. In a smaller pool, you will get bigger, less frequent payouts. Solo you will get rare, big payouts.
As to the pool question, since everything is probability and luck with mining, dividing your miners between pools or keeping them on one pool really doesn't matter. Go solo, divide them up, put them on the same pool - over the long haul it will even out. In a bigger pool you will get smaller, more frequent payouts. In a smaller pool, you will get bigger, less frequent payouts. Solo you will get rare, big payouts.
Jump to: