Topic: Phoenix - Efficient, fast, modular miner - page 16. (Read 760569 times)
FYI, phoenix now works with OS X in Lion. It appears that Apple updated their twisted library sufficiently that phoenix is now happy to run.
Is there any chance of getting the --backup flag added/working? I use Guiminer with Phoenix, and being able to switch to a backup pool is about the only thing I'm missing right now.
Thanks!
Thanks!
Was mining fine at first, then this happened (100% rejected), on btcguild (USWest).
Meanwhile my poclbm miners on same rig were fine, so it seems something is wrong...
This was with r112 -k phatk VECTORS BFI_INT AGGRESSION=13 FASTLOOP=false WORKSIZE=256
Meanwhile my poclbm miners on same rig were fine, so it seems something is wrong...
This was with r112 -k phatk VECTORS BFI_INT AGGRESSION=13 FASTLOOP=false WORKSIZE=256
the core/mem clock is 850/180, I've run at this clock for more than a month and happy with this 
However, when I changed the clock to 850/300, the speed went back to ~361, a litte better than before.
ps: my other 5850s, at 850/180 clock with the lastest poclbm, the speed is around 360Mhash.
/Diapolo: Thanks for the hard work on optimizing phatk kernel. Really appreciate it.
However, when I changed the clock to 850/300, the speed went back to ~361, a litte better than before.
ps: my other 5850s, at 850/180 clock with the lastest poclbm, the speed is around 360Mhash.
/Diapolo: Thanks for the hard work on optimizing phatk kernel. Really appreciate it.
That huge drop seems weird ... a 5850 should benefit from the new kernel. What's your cards mem clock?
Jedi, on which of my versions is your kernel based? Did you use the one with modified init file? I hope it's not a "Linux thing", I'm on Win7 x64 and a 5830 and 5870 is faster than with the original phatk.
Dia
Jedi, on which of my versions is your kernel based? Did you use the one with modified init file? I hope it's not a "Linux thing", I'm on Win7 x64 and a 5830 and 5870 is faster than with the original phatk.
Dia
Quote
r112 | jedi95 | 2011-07-18 13:09:01 +0900 (Mon, 18 Jul 2011) | 1 line
Performance improvement for phatk
just updated to r112, but got my speed slow down from ~360Mhash --> ~330Mhash (Ubuntu 11.4, SDK 2.4, phatk on a 5850 850MHz). Rolled back to r111 & waiting for news.Performance improvement for phatk
Odd, I'm running phatk r112 on 4 5870s and a 5830. The hashrate is slightly higher than what I get with r111.
I didn't make these particular changes to phatk, see this thread:
http://forum.bitcoin.org/index.php?topic=25860.0
Quote
r112 | jedi95 | 2011-07-18 13:09:01 +0900 (Mon, 18 Jul 2011) | 1 line
Performance improvement for phatk
just updated to r112, but got my speed slow down from ~360Mhash --> ~330Mhash (Ubuntu 11.4, SDK 2.4, phatk on a 5850 850MHz). Rolled back to r111 & waiting for news. Performance improvement for phatk
After a lot of flailing around and hair pulling, I managed to get my dual card, dual monitor setup working. I also found out how to crank up my GPU fan speed, and my rig is now mining along at about 540 MH/s with GPU temps of 72 and 65.
I'm new here, and I hope this isn't a dumb FAQ. I've successfully mined a bit with phoenix on an XFX 6790 under Debian Squeeze with SDK 2.4. Today I added a Diamond 6970, and it seems that I don't know how to mine on dual cards yet. I have one monitor plugged into each card, running with XINERAMA=on, if that matters. When I run phoenix, it's only mining on the first GPU (which happens to be the 6970). If I try DEVICE=1, then it runs on the built-in GPU in my CPU. Any hints for a clueless noob?
While I'm here, I notice that the 6970 runs a lot hotter than the 6790. With little or no overclocking, the 6970 is running at 90 deg. C while the 6790 runs at around 68 deg. C.
While I'm here, I notice that the 6970 runs a lot hotter than the 6790. With little or no overclocking, the 6970 is running at 90 deg. C while the 6790 runs at around 68 deg. C.
I read the first few posts, but obviously i didn't read the entire thread so I wouldn't know if it's been answered yet but is there any way to add some sort of delay? I made it aggression level=0 but i still feel it's too fast and would make the laptop too hot and stuff
Quote
The rewrite for the RPC protocol is finished, and has been uploaded to the SVN.
It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.
It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.
i tested it and it resulted in constant disconnects from btcguild (all servers). I reverted back to r110 and the problem disappeared.
Quote
The rewrite for the RPC protocol is finished, and has been uploaded to the SVN.
It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.
It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.
i tested it and it resulted in constant disconnects from btcguild (all servers). I reverted back to r110 and the problem disappeared.
Same here. I ran r111 against Chris Howie's mining proxy (on the same machine, so there shouldn't be any real connection issues), and got lots and lots of disconnects and idles. With r110 it works flawlessly.
The rewrite for the RPC protocol is finished, and has been uploaded to the SVN.
It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.
It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.
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%
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.
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?
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%
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
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.
+ you can use granola software & put it in lowest speed(for some strange reason MiserWare also uses more CPU), that will put the temperature of that core under 65C & also you won't feel any lagging in windows.
I have 2 * 5870 GPU's mining in Windows 7 with Aero enabled giving 434 & 442 Mhash/s
Jump to: