Phoenix 2 beta discussion

[CFSworks]

Ok, I got things to work. Is there a way to have one GPU mine at one backend and have the other GPU mining at a different backend?

You would have to dedicate each GPU to a different Phoenix process to do that. The Phoenix core is currently designed to connect to only one backend.

[Bananington]

I'm trying to use another kernel and I can't seem to get it right. I keep getting the "failed to load kernel 'phatk'" message in the console.
Here's what I've worked out so far. The kernel I want to use is in the folder with the other kernel's and it's named "phatk"

Code:

[general]
verbose = True
backend = http://censored:8332

[cl:0:0]
disabled = True
kernel = phatk
AGGRESSION = 12
VECTORS2 = true
WORKSIZE = 128

[cl:0:1]
kernel = phatk
AGGRESSION = 12
VECTORS2 = true
WORKSIZE = 128

[web]
disable = true

[CFSworks]

I'm trying to use another kernel and I can't seem to get it right. I keep getting the "failed to load kernel 'phatk'" message in the console.

Kernels developed for Phoenix 1.x are not directly compatible with Phoenix 2, but the required changes are minimal.

If the phatk kernel were updated to be compatible, it would work. I can't think of any benefit to doing so, though. The phatk2 kernel outperforms phatk on all hardware we've tested with.

[ssateneth]

Hi, testing out phoenix 2. Didnt instant crash my computer like some other miners do which is good. Seems to be identical performance too as far as hash rates go, just have to explicitly define all variables since they aren't assumed anymore due to the lack of init.py (my bad, its the bfi_patcher.py thats gone now, probably integrated in phoenix.exe). Is it possible to have better granularity of the hashrate? GUIMiner + Phoenix 1.7.4 is able to show 1.178 ghash, but with phoenix 2, I lose a digit and only shows 1.17 ghash. On another rig, it shows 2 more digits of the hash rate (766.73 mhash, etc). How about giving the same treatment to Ghash?

Thanks for continuing to support multiple OpenCL platforms. Works well for my 2.1 + 2.6 SDK setup.

Also with the upcoming web interface, will it be possible to alter aggression of specific devices on the fly?

Lastly, I took a quick look through the kernel and found BITALIGN. Under what hardware is this supported? I tried this instead of BFI_INT and saw a much lower hash rate on my 5830/5870's. Is it supposed to be faster? Is it supposed to work in conjunction with BFI_INT?

Bananington, VECTORS2 is unused. Use VECTORS or VECTORS 4. Also make sure to define BFI_INT = true for each device that supports it, and don't forget your user/pass combo in the backend. http://user:pass@website:port

[ZPK]

i use aoclbf by wind 1.81 for overclocking  videocards.......then open him phoenix down 100%
for mining use original phoenix.

and please say wtf is it ?
http://d.pr/sq8t
http://d.pr/D4sI

[ssateneth]

just got an error. one of my cards is no longer mining (no gpu activity), probably need to restart the phoenix.exe. win7 x64, driver 11.12, sdk 2.6 + sdk 2.1. miner shows abnormal hash rate. 27 ghash wtf?

[ZPK]

please add to phoenix overclocking support...

[ZPK]

just got an error. one of my cards is no longer mining (no gpu activity), probably need to restart the phoenix.exe. win7 x64, driver 11.12, sdk 2.6 + sdk 2.1. miner shows abnormal hash rate. 27 ghash wtf?

hmm...i use 2 hours and do not see that. windows 7 sp1 x64,11.6 drivers

5850  960/300 60%
[cl:0:0]
autoconfigure = False
disabled = False
bfi_int = True
vectors = True
worksize=256
aggression=12

[bangra]

Running on 2x 5870, might update my main rigs later

without the aggression entry cards only run at 95%, now added to config and everything seems to be ok and maybe gained a few Mhs

[d3m0n1q_733rz]

just got an error. one of my cards is no longer mining (no gpu activity), probably need to restart the phoenix.exe. win7 x64, driver 11.12, sdk 2.6 + sdk 2.1. miner shows abnormal hash rate. 27 ghash wtf?

I didn't have the hardware stop mining completely, but I also experienced the slight hiccup that showed my miner as having a hash rate in the 400's when I'm lucky to break 15.  However, it didn't stop mining and I managed to get an accepted while it hiccuped.  This could just be a lower priority on measuring hash rate.

[bulanula]

Will this include automatic fan and gpu management like cgminer ?

What about killing mining thread on GPU that has a dead fan while I am away ?

IMHO cgminer is good because of auto fan feature and support for backup pools and screw all that python BS.

Thank you !

[ZPK]

Will this include automatic fan and gpu management like cgminer ?

What about killing mining thread on GPU that has a dead fan while I am away ?

IMHO cgminer is good because of auto fan feature and support for backup pools and screw all that python BS.

Thank you !

very huge ....eyes in panic....no need thx )

for first settings can do gui, and if all work gui off.

[HendrikJan]

First impression: Looks real good!

But i would like to like to know what "Roling time" means.
Also the overclock option mentioned before would be nice.

For now i get 10Mh/s less but i still have to use some fine tuning in the config file.

[bangra]

Changed over main rigs and been running all day, just had 1 card crash and readings jumped to 18Ghash then dropped back to 1.9 ghash when should have been 1.5ghash, would be great to have somthing that could detect a card stopping and restart it, running on Win7 x64 5x 5850

[Diapolo]

Got DiaKGCN working ^^, will be released in the next 2 days!

One thing, hashrate display seems a bit crazy currently ... starts at 5 GHash/s and takes forever to reach normal levels, where it belongs. Perhaps this can be reworked!?
Oh, and I think BFI_INT whitelist should reside in the kernels init file and not be placed somewhere else . PyOpenCL is still 0.92 are there any news in terms of higher AGGRESSION levels and getwork delays?

Edit: CPU utilisation looks way better, than with Phoenix 1.X!

Dia

[scifimike12]

Still about 4 Mh/s slower than Diablominer with my 7970 at stock settings (925/1375).

Settings:

Code:

[cl:0:0]
autoconfigure = false
disabled = false
bfi_int = false
vectors = true
worksize = 256
aggression = 10

If I set aggression to 12, it will be about dead even but I get CPU load bug.  Keeping it 10 seems to leave it at idle.

[Kluge]

249 shares accepted, 1 rejected, ~5MH/s higher than on original phatk.

Yeah, I like it. 

ETA: After another hour, reject rate is 0.72% on EMC.

[jedi95]

Got DiaKGCN working ^^, will be released in the next 2 days!

One thing, hashrate display seems a bit crazy currently ... starts at 5 GHash/s and takes forever to reach normal levels, where it belongs. Perhaps this can be reworked!?
Oh, and I think BFI_INT whitelist should reside in the kernels init file and not be placed somewhere else . PyOpenCL is still 0.92 are there any news in terms of higher AGGRESSION levels and getwork delays?

Edit: CPU utilisation looks way better, than with Phoenix 1.X!

Dia

I think I know what's causing the hashrate display to initially show a huge value. I will fix this later today.

The reason we decided to put the BFI_INT whitelist in BFIPatcher.py was so that it wouldn't need to be duplicated across all kernels. This also makes it simpler to update since we only need to change it in one place. Kernels can still include their own whitelist if they want.

I will retest the newer PyOpenCL versions, but I highly doubt there will be any differences from previous tests.

[d3m0n1q_733rz]

Still about 4 Mh/s slower than Diablominer with my 7970 at stock settings (925/1375).

Settings:

Code:

[cl:0:0]
autoconfigure = false
disabled = false
bfi_int = false
vectors = true
worksize = 256
aggression = 10

If I set aggression to 12, it will be about dead even but I get CPU load bug.  Keeping it 10 seems to leave it at idle.

Me and Diapolo each have something for you to try.  Mine is a bit of an insane move, but Dia's has some very nice code.  I'll attempt to port my mod over tonight/this evening/in about 5 hours or so.

[Diapolo]

Got DiaKGCN working ^^, will be released in the next 2 days!

One thing, hashrate display seems a bit crazy currently ... starts at 5 GHash/s and takes forever to reach normal levels, where it belongs. Perhaps this can be reworked!?
Oh, and I think BFI_INT whitelist should reside in the kernels init file and not be placed somewhere else . PyOpenCL is still 0.92 are there any news in terms of higher AGGRESSION levels and getwork delays?

Edit: CPU utilisation looks way better, than with Phoenix 1.X!

Dia

I think I know what's causing the hashrate display to initially show a huge value. I will fix this later today.

The reason we decided to put the BFI_INT whitelist in BFIPatcher.py was so that it wouldn't need to be duplicated across all kernels. This also makes it simpler to update since we only need to change it in one place. Kernels can still include their own whitelist if they want.

I will retest the newer PyOpenCL versions, but I highly doubt there will be any differences from previous tests.

Thanks for your answer, I'm looking forward to your tests and the fixed hashrate display. I'm interested in how you achieved the lower CPU usage in comparision to the original Phoenix.
Oh and can I supply a backup pool as with Phoenix or any failover strategy?

Dia