|
Could you include affinity options in the next release? I'm having issues with phoenix using 50% CPU per GPU. By setting affinity to cpu1 (of 2) it'll use 100% of that core rather than 100% of both.
|
|
|
|
I'm running 11.7. Runs fine minus the CPU issue with phoenix. Very stable and does eliminate the need for a dummy plug. Found out about 11.7 minutes after I ordered 20 resistors.  Ouch, at least they're cheap, I guess. $2.50 for 20 68ohm resistors, shipped. Whatever. Re: 11.6B, I've had issues with phoenix using 50% of my CPU PER GPU. The fix is to set affinity to just one core. It'll use 100% of it but that will minimize other cores being used. http://forum.bitcoin.org/index.php?topic=28392.0 |
|
|
|
I'm running Phoenix 1.5 and the CPU usage is insane. I have a 4870 and a 5830 in my miner. The 5830 gets about 307mh/s while the 4870 gets 80 or so mh/s.
When they're both running, Phoenix is running twice and using 48-50% CPU each. That just means it doesn't matter your hash rate, just that you're running the kernel, or so it seems. I've got a Core 2 Duo overclocked to 3.2ghz. I really can't imagine this needs that much processing power.
Any idea how I can fix this?
Have you used GPU Caps Viewer by any chance? Can you post screenshots of its tabs? This will happen if your CPU supports the OpenCL instruction set (e.g.: integrated graphics card/and-or shared memory GPU) and you happen to target that device in the miner. I did that accidentally a couple of times and was shocked to see the CPU usage spike before I figured out what happened. Nah, that's not the issue. When only one GPU is mining, CPU usage is 50%. If I were accidentally mining with the CPU, it'd be at 100. |
|
|
|
|
Alright, we just had a 22 hour round followed by a 10 hour round. wtf
Call it luck, odds, stats, whatever, this blows.
edit: Site just updated. Before, the previous round was 22 hours and current was 10. Well the current is still 10 but now it shows previous as 3 hours. I was also just paid for blocks 136358, 136379.
|
|
|
|
I'm running 11.7. Runs fine minus the CPU issue with phoenix. Very stable and does eliminate the need for a dummy plug. Found out about 11.7 minutes after I ordered 20 resistors. |
|
|
|
|
The whole site is going to be down for 30 min?
|
|
|
|
|
Where's the link to that pie chart?
|
|
|
|
|
on the site, it says I've got 386mh/s. On my machine I've got one running at 304 and another GPU at 97mh/s. Those figures aren't fluxuating so I'm wondering why that's not matching up with the site.
|
|
|
|
Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.
Well, on my system it goes like this: 1% CPU with AGGRESSION=9 17% CPU with AGGRESSION=10 33% CPU with AGGRESSION=11 This is with an Athlon 64 X2 6000+, one 6870 card and Catalyst 11.6/SDK 2.4 Well, I have no idea what's going on there. If you were having the problem described above your CPU load would be pegged at 50% (1 core out of 2 at 100%) regardless of miner settings. I don't know how it can end up using more CPU at higher aggression, since there are fewer kernel executions per second. On miners without the 100% problem the most CPU usage I have seen is 2-3% The 11.7 driver that is being used causes a CPU core to go to 100% usage per miner instance. That is what changed in the previous poster's setup. Reverting to 11.6/SDK 2.4 will likely solve the problem. I've tried it with 11.2, same issue. It's not 11.7 only. |
|
|
|
Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.
Well, on my system it goes like this: 1% CPU with AGGRESSION=9 17% CPU with AGGRESSION=10 33% CPU with AGGRESSION=11 This is with an Athlon 64 X2 6000+, one 6870 card and Catalyst 11.6/SDK 2.4 Well, I have no idea what's going on there. If you were having the problem described above your CPU load would be pegged at 50% (1 core out of 2 at 100%) regardless of miner settings. I don't know how it can end up using more CPU at higher aggression, since there are fewer kernel executions per second. On miners without the 100% problem the most CPU usage I have seen is 2-3% And the only way around this is to either mine with one card or change affinity? I'll have to knock the CPU OC back down to 2.6 to save on heat/electric. This is a major bummer. Is there any way we could inform ATI of the bug to get it ironed out? |
|
|
|
I'm getting this even when running one GPU mining. The other is in the machine just not doing anything.
Well that would not really matter, if it's mining or not. As long as it's connected to the computer, the bug still comes up. That's a bummer. This is from another thread ( http://forum.bitcoin.org/index.php?topic=6458.800): Yep, it's pretty bad. 50% cpu usage per GPU. Something is seriously wrong.
Wow I checked this for my system (Phenom II X6 / Win7 x64 SP1) and Phoenix 1.5 eats one FULL CPU core per instance running (2 GPUs - 2 Cores eaten). I downclock the cores to 800 MHz each, for Mining so one could think, if I raise the core freq. it will only use 1 core for 2 or more cards. No it eats one core and it doesn't matter, if it's clocked at 800 MHz or 3200 MHz, THAT IS crazy. Jedi, is there any explanation for this, can we help to track the issue down!? Dia Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all. |
|
|
|
The only fix I have found with my own setup for this, is not using Phoenix.
And I have tried a lot of different driver/sdk combinations, of course.Inspired by your post, I made an effort to try phoenix once again with the latest Diapolo kernel. Working fine at ~1% cpu usage. Win7 32bit, cat11.6, SDK 2.1, hd5870 But it's most likely a dual GPU thing... When I had 2 cards in my rig, there was nothing I could do, to fix the cpu usage bug in windows. Also it's probably not such a good idea to overclock your cpu, if you're mining. Rather underclock. I'm getting this even when running one GPU mining. The other is in the machine just not doing anything. |
|
|
|
|
I should also add that phoenix is taking 50% CPU from both cores.
|
|
|
|
1000mhz is quiet high... maybe you have reached the cards limits. Every card is different, some can do 1050, some only 900. One of mine only does 950.
Try with normal memory clocks and see if that helps. You can check for artifacts with OCCT or any other tool (They may give different results). If you get any artifact, thats probably the card's limit.
You could also try moving the problem card to the best-vented slot to get it cooler. This also has the advantage that it's not the primary display and crashes may recover easier.
You may be able to do 1000 if you bump the voltage up a bit. Of course, do so at your own risk. You're right, I put it to 980 and it does quite well. |
|
|
|
|
I'm running Phoenix 1.5 and the CPU usage is insane. I have a 4870 and a 5830 in my miner. The 5830 gets about 307mh/s while the 4870 gets 80 or so mh/s.
When they're both running, Phoenix is running twice and using 48-50% CPU each. That just means it doesn't matter your hash rate, just that you're running the kernel, or so it seems. I've got a Core 2 Duo overclocked to 3.2ghz. I really can't imagine this needs that much processing power.
Any idea how I can fix this?
|
|
|
|
|
I'll pay you to send you a google+ invite!
... yah right
|
|
|
|
|
Yep, it's pretty bad. 50% cpu usage per GPU. Something is seriously wrong.
|
|
|
|
|
So the answer is b). I'm an idiot.
Thanks, I see it now. I've no idea why the huge brain fart.
|
|
|
|
Ok, here's what I'm trying to figure out. With prior versions, there was a wallet.dat file which I encrypted. Then I quit bitcoin, opened it up again and a new wallet.dat was made. I made the encrypted wallet my savings wallet and the new one my temporary. I could then swap one out for the other depending on what I needed to do.
I've got both wallets right now and I'm not sure how to import either the temp one or the savings one into bitcoin. I really don't want to proceed further because I don't want to harm my savings wallet.
The exact same way you always did. Nothing in terms of wallet handling has changed. Weird. Before, when I encrypted and moved the savings wallet.dat, for example, I'd reopen bitcoin and a new wallet.dat would be created. I'm either not remembering where bitcoin keeps wallet.dat or something's different. Or I'm an idiot and forgot wtf is going on. How do you protect your wallet? |
|
|
|
Ok, so when bitcoin is running, shouldn't wallet.dat be in the same directory as wallet.h and wallet.cpp?
No, wallet.* are source code for the program, they don't belong with the wallet largely because the entire source directory is not needed to run the program. Ok, here's what I'm trying to figure out. With prior versions, there was a wallet.dat file which I encrypted. Then I quit bitcoin, opened it up again and a new wallet.dat was made. I made the encrypted wallet my savings wallet and the new one my temporary. I could then swap one out for the other depending on what I needed to do. I've got both wallets right now and I'm not sure how to import either the temp one or the savings one into bitcoin. I really don't want to proceed further because I don't want to harm my savings wallet. |
|
|
|
|
Show Posts
