Bitcoin Forum

Bitcoin => Mining software (miners) => Topic started by: CFSworks on February 06, 2012, 04:32:07 AM



Title: Phoenix 2 beta discussion
Post by: CFSworks on February 06, 2012, 04:32:07 AM
Phoenix 2.0.0-rc2

The features of the new Phoenix 2 include:
Settings are stored in a single configuration file
No more managing hideously long command lines. Phoenix 2 loads them from a configuration file.

Multi-device mining from a single Phoenix process
You only have to launch one Phoenix process and it will manage multiple devices. The devices even share the same work queueing system for maximum efficiency.

Hardware autodetect (including hotplug support) and autoconfiguration
Kernels can now recommend optimal configurations for hardware. All you have to do is turn on autodetect and let Phoenix do its magic.

A better kernel interface supporting modern hardware miners
Kernels can now request full work units from the queue - ask your hardware vendors about making a Phoenix 2 kernel!

Complete JSON-RPC API
The RPC server listens on port 7780 by default, and is configurable through the config file.

Web control panel (not finished)
The RPC server also hosts a webserver. When the control panel is finished, you will be able to do first-time miner setup and long-term management through the web interface. If you are a web developer, consider looking at our PhoenixWeb Github repository and helping out.

Getting started
Download
You can find our repository on Github (http://github.com/phoenix2).
Windows users: see jedi95's post below. He is in charge of Windows builds.
Linux users can find the source code archive here (https://github.com/phoenix2/phoenix/tarball/v2.0.0-rc2).

Install
Windows users only need to extract the .zip into a new folder.
Linux users need to make sure all of the Phoenix 1 prerequisites are installed, and then run "./setup.py install" as root.

Configure
Windows users run the .exe to create a blank .cfg, then close it. (In the future, the configuration will occur through the web interface.)
Linux users create a .cfg, put "#!/usr/bin/env phoenix" at the top, and "chmod u+x" it.

An example configuration to get you started:
Code:
[general]
verbose = True
autodetect = +cl -cpu # The rightmost parameter takes precedence. This enables all OpenCL devices, except those that are CPUs.
backend = YOUR_URL_HERE # URL format is exactly as it was in Phoenix 1
backups = URL1 URL2 URL3 URL4 # Any number of backup backends (space-separated) to use in case the primary backend goes down.

[web]
password = rpc_password # Set an RPC password to keep people from messing with your miners.

# If you want to configure miners yourself, edit and uncomment this section:
#[cl:0:0] # Or whatever ID you want to configure.
#autoconfigure = True # Do you still want autoconfiguration?
#disabled = False # Do you want to disable the miner?
#bfi_int = True    # And any other kernel options...
#vectors = False # ...can go into this section.

Run
On Linux, simply execute your configuration file. It will launch Phoenix.
On Windows, run the .exe again

Please note: This thread is for discussing the development of Phoenix 2 only. Phoenix 1.x questions need to go to this thread (https://bitcointalk.org/index.php?topic=6458.0) and a new thread will be created when Phoenix 2 itself is released.

Donations gratefully accepted at: 1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
And there is a bounty for a web control panel here (https://bitcointalk.org/index.php?topic=63970.0)


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: jedi95 on February 06, 2012, 04:32:14 AM
Windows binaries:
https://github.com/downloads/phoenix2/phoenix/phoenix-2.0.0-rc2.zip

Phoenix 1.7.x is now a legacy branch and will only see limited further development.

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


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: rjk on February 06, 2012, 04:35:37 AM
If you don't have it already, proper support for RollNTime with expire=N would be a very useful feature for fast miners.

EDIT: Link to wiki page with list of miners and pools supporting various features: https://en.bitcoin.it/wiki/Getwork_support


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: CFSworks on February 06, 2012, 04:37:46 AM
If you don't have it already, proper support for RollNTime with expire=N would be a very useful feature for fast miners.

EDIT: Link to wiki page with list of miners and pools supporting various features: https://en.bitcoin.it/wiki/Getwork_support

We do have it. I suppose I should have put it in the features list... ;D


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: rjk on February 06, 2012, 04:46:04 AM
If you don't have it already, proper support for RollNTime with expire=N would be a very useful feature for fast miners.

EDIT: Link to wiki page with list of miners and pools supporting various features: https://en.bitcoin.it/wiki/Getwork_support

We do have it. I suppose I should have put it in the features list... ;D
Excellent. The unified queue manager is also an excellent new feature - one that most miners don't have and have needed for a long time.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 06, 2012, 04:47:34 AM
Autodetect could use some work.  It would seem that it doesn't take vectors and optimum worksize into account.  How would one go about modifying the configuration file to set parameters manually?  I'm wanting to toss VECTORS8 in with a worksize of 64 while applying Dia's GOFFSET option if I can.  It would be nice to know the new layout.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: CFSworks on February 06, 2012, 04:53:57 AM
Autodetect could use some work.  It would seem that it doesn't take vectors and optimum worksize into account.
That's jedi95's department. He's on it.

How would one go about modifying the configuration file to set parameters manually?  I'm wanting to toss VECTORS8 in with a worksize of 64 while applying Dia's GOFFSET option if I can.  It would be nice to know the new layout.
Forgot to put that in the first post. I updated the example config file to show how you can do it. You will need to know the device ID of your hardware (cl:PLATFORM:DEVICE) and you can override the autoconfigured settings (or disable autoconfiguration completely) from the config file.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Bananington on February 06, 2012, 04:54:39 AM
How would I have autoconfigure enabled on one out of two installed VGA's?


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: CFSworks on February 06, 2012, 05:00:03 AM
How would I have autoconfigure enabled on one out of two installed VGA's?

If you don't want to autodetect, you can do:
Code:
[cl:0:0]
autoconfigure = False
#settings here

[cl:0:1]
autoconfigure = True

If you do want to autodetect, you can just omit the one that has autoconfigure = True.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 06, 2012, 05:04:50 AM
How would I have autoconfigure enabled on one out of two installed VGA's?

If you don't want to autodetect, you can do:
Code:
[cl:0:0]
autoconfigure = False
#settings here

[cl:0:1]
autoconfigure = True

If you do want to autodetect, you can just omit the one that has autoconfigure = True.
I'll give this a try.  I assume it's similar to passing the settings to the command-line based version?  Just all the little ducks in a row?


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: CFSworks on February 06, 2012, 05:05:54 AM
I assume it's similar to passing the settings to the command-line based version?  Just all the little ducks in a row?

Yes. The kernels are very similar, so the kernel options are pretty much the same as in Phoenix 1.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Bananington on February 06, 2012, 05:08:04 AM
In the example, it says "backend = UR_URL_HERE"; is that where I put my worker information?


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 06, 2012, 05:11:39 AM
In the example, it says "backend = UR_URL_HERE"; is that where I put my worker information?
That's where you put your worker and site info. combined.  Like http://My_miner_name:Miner Password@www.website.net:8332


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 06, 2012, 05:21:50 AM
Could we get a list of all accepted options?
Kernel selection
Worksize=
Vectors, Vectors4, Vectors8, Vectors16
etc.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Bananington on February 06, 2012, 05:26:45 AM
I can't get the miner to start.  ???
This is what I've got exactly in my cfg file. lol
Code:
[cl:0:0]
autoconfigure = True

[cl:0:1]
autoconfigure = True
backend = http://censored:censored@censored.com:8332

I also want to have GPU 2(Device #1) mine while GPU 1(Device #0) is not mining. But I also want to have GPU 1 set up to mine so that I can just enable it to mine by changing a value of some sort.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 06, 2012, 05:30:15 AM
I can't get the miner to start.  ???
This is what I've got exactly in my cfg file. lol
Code:
[cl:0:0]
autoconfigure = True

[cl:0:1]
autoconfigure = True
backend = http://censored:censored@censored.com:8332

I want to have GPU 2(Device #1) mine while GPU 1(Device #0) is not mining. But I also want to have GPU 1 set up to mine so that I can just enable it to mine by changing a value of some sort.

Best bet would be to put the program in two different folders.  Close the program from the folder you have the cfg set for disabling GPU1 and then start the program for both GPU mining when you want to have them both working. 


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 06, 2012, 05:37:11 AM
[cl:0:0]
autoconfigure = False
BFI_INT VECTORS4 WORKSIZE=64

What's wrong with this portion that it's not giving me the correct settings?


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Bananington on February 06, 2012, 05:38:43 AM
I can't get the miner to start.  ???
This is what I've got exactly in my cfg file. lol
Code:
[cl:0:0]
autoconfigure = True

[cl:0:1]
autoconfigure = True
backend = http://censored:censored@censored.com:8332

I want to have GPU 2(Device #1) mine while GPU 1(Device #0) is not mining. But I also want to have GPU 1 set up to mine so that I can just enable it to mine by changing a value of some sort.

Best bet would be to put the program in two different folders.  Close the program from the folder you have the cfg set for disabling GPU1 and then start the program for both GPU mining when you want to have them both working.  
My problem isn't the whole GPU thing right now, that was just a side note. My real problem is that I have NO IDEA what settings to use for where and for what. My miner won't mine due to PEKAC.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: CFSworks on February 06, 2012, 05:39:05 AM
Could we get a list of all accepted options?
Kernel selection
Worksize=
Vectors, Vectors4, Vectors8, Vectors16
etc.

The Phoenix 2 core itself recognizes (not an exhaustive list):
Code:
# [cl:0:0] autoconfigure # Allow the kernel to choose its own configuration variables?
# [cl:0:0] disabled # Prevent mining on this device?
# [cl:0:0] kernel # Can be used to manually choose a kernel to mine on.
# [cl:0:0] start_undetected # Start even if autodetect doesn't find it?
# [general] autodetect # A list of rules for what devices to autodetect.
# [general] backend # The URL to mine on in the backend.
# [general] logfile # Set this option to log to a file.
# [general] queuedelay # Advanced - ???
# [general] queuesize # Advanced - ???
# [general] ratesamples # Advanced - number of samples to average for rate reporting
# [general] statusinterval # Advanced - how long to delay between statusbar updates
# [general] verbose # Enable verbose mode? (Shows debug messages)
# [web] bind # Bind the web/RPC server to a specific IP
# [web] disabled # Disable the webserver altogether?
# [web] logbuffer # Advanced - how many logs to remember in the getlogs() RPC call
# [web] password # The password necessary for web/RPC login (username is ignored)
# [web] port # What port should the web/RPC server listen on?
# [web] root # Advanced - The root directory for the webserver.

The phatk2/opencl kernels recognize:
Code:
# [cl:0:0] vectors # Enable two-way vectors?
# [cl:0:0] vectors4 # Enable four-way vectors?
# [cl:0:0] fastloop # Advanced - fastloop optimization for low aggressions
# [cl:0:0] aggression # Controls how hard Phoenix 2 hits the hardware
# [cl:0:0] worksize # Advanced - controls size of individual executions
# [cl:0:0] bfi_int # Enable BFI_INT optimization for Radeon cards that support it

[cl:0:0]
autoconfigure = False
BFI_INT VECTORS4 WORKSIZE=64

What's wrong with this portion that it's not giving me the correct settings?

Try:
Code:
[cl:0:0]
autoconfigure = false # Not actually needed since autoconfiguration disables by default when you supply your own args
BFI_INT = true # Also the boolean options aren't case sensitive.
VECTORS4 = true
WORKSIZE = 64


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Bananington on February 06, 2012, 05:50:04 AM
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?


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: CFSworks on February 06, 2012, 05:53:32 AM
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.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Bananington on February 06, 2012, 06:15:11 AM
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


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: CFSworks on February 06, 2012, 06:22:58 AM
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.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: ssateneth on February 06, 2012, 09:02:19 AM
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


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: ZPK on February 06, 2012, 09:35:16 AM
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


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: ssateneth on February 06, 2012, 10:33:32 AM
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?
http://dl.dropbox.com/u/9768004/error.png


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: ZPK on February 06, 2012, 10:38:38 AM
please add to phoenix overclocking support...


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: ZPK on February 06, 2012, 10:41:40 AM
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?
http://dl.dropbox.com/u/9768004/error.png


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


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: bangra on February 06, 2012, 11:10:57 AM
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


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 06, 2012, 11:14:21 AM
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?
http://dl.dropbox.com/u/9768004/error.png
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.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: bulanula on February 06, 2012, 11:28:32 AM
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 !


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: ZPK on February 06, 2012, 11:41:51 AM
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.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: HendrikJan on February 06, 2012, 05:18:05 PM
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.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: bangra on February 06, 2012, 06:15:38 PM
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


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Diapolo on February 06, 2012, 06:58:13 PM
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


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: scifimike12 on February 06, 2012, 07:36:40 PM
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.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Kluge on February 06, 2012, 07:39:17 PM
249 shares accepted, 1 rejected, ~5MH/s higher than on original phatk.

Yeah, I like it.  ;D

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


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: jedi95 on February 06, 2012, 07:55:28 PM
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.



Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 06, 2012, 08:17:56 PM
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.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Diapolo on February 06, 2012, 08:24:57 PM
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


Title: DiaKGCN for Phoenix2 preview
Post by: Diapolo on February 06, 2012, 08:31:17 PM
For the ones, who want to try DiaKGCN with Phoenix 2, here is a preview:
http://www.filedropper.com/diakgcnphoenix2preview_1

This can be used as config:

Code:
[cl:0:0]
autoconfigure = false
kernel = diakgcn
aggression = 12
vectors2 = true
vectors4 = false
vectors8 = false
worksize = 256

The kernel is the same as the last version for Phoenix 1.7.X, only has some small fixes in the init.

Please report bugs, glitches, ideas and results back to me, thanks!

Dia


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: lodcrappo on February 06, 2012, 08:40:02 PM
please add to phoenix overclocking support...

please no.  don't turn phoenix into the monstrosity of some other miners.  it's simplicity is it's beauty.

do one thing, and do it well.

when you throw everything possible into one program, you end up with too many compromises.



Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: bulanula on February 06, 2012, 08:49:20 PM
please add to phoenix overclocking support...

please no.  don't turn phoenix into the monstrosity of some other miners.  it's simplicity is it's beauty.

do one thing, and do it well.

when you throw everything possible into one program, you end up with too many compromises.



I 100% agree and support this decision. Remember the KISS principle. If you need OC stick to AMD API thing.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: HendrikJan on February 06, 2012, 09:41:21 PM
I did try the diakgcn kernel.
Still about 10Mh/s less then older version.

Also would like to know what the "Rolling time" is.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Barlog on February 06, 2012, 09:46:56 PM
You will need new address for donations aka 2PHoenix  :D


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 06, 2012, 11:04:57 PM
Alright, I have a register spill somewhere in here...can someone find it for me?  I'm using 8 vectors to make better use of the 16 available to the HD79xx cards.  But the code itself isn't made to handle it.  I just can't figure out what part needs to be changed to make it capable.   :-[

Code:
// This file is in the public domain

#ifdef VECTORS8
typedef uint8 u;
#elif defined VECTORS4
typedef uint4 u;
#elif defined VECTORS
typedef uint2 u;
#else
typedef uint u;
#endif

__constant uint K[64] = {
0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
};

__constant uint ConstW[128] = {
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x80000000U, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000280U,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,

0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x80000000U, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000100U,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
};

__constant uint H[8] = {
0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19
};

#ifdef BITALIGN
#pragma OPENCL EXTENSION cl_amd_media_ops : enable
#define rot(x, y) amd_bitalign(x, x, (uint)(32 - y))
#else
#define rot(x, y) rotate(x, (uint)y)
#endif

// Some AMD devices have the BFI_INT opcode, which behaves exactly like the
// SHA-256 Ch function, but provides it in exactly one instruction. If
// detected, use it for Ch. Otherwise, use bitselect() for Ch.

#ifdef BFI_INT
// Well, slight problem... It turns out BFI_INT isn't actually exposed to
// OpenCL (or CAL IL for that matter) in any way. However, there is
// a similar instruction, BYTE_ALIGN_INT, which is exposed to OpenCL via
// amd_bytealign, takes the same inputs, and provides the same output.
// We can use that as a placeholder for BFI_INT and have the application
// patch it after compilation.

// This is the BFI_INT function
#define Ch(x, y, z) amd_bytealign(x,y,z)
// Ma can also be implemented in terms of BFI_INT...
#define Ma(z, x, y) amd_bytealign(z^x,y,x)
#else
#define Ch(x, y, z) bitselect(z,y,x)
#define Ma(x, y, z) bitselect(x,y,(z^x))
#endif

//Various intermediate calculations for each SHA round
#define s0(n) (S0(Vals[(128 - (n)) % 8]))
#define S0(n) (rot(n, 30u)^rot(n, 19u)^rot(n,10u))

#define s1(n) (S1(Vals[(132 - (n)) % 8]))
#define S1(n) (rot(n, 26u)^rot(n, 21u)^rot(n, 7u))

#define ch(n) Ch(Vals[(132 - (n)) % 8],Vals[(133 - (n)) % 8],Vals[(134 - (n)) % 8])
#define maj(n) Ma(Vals[(129 - (n)) % 8],Vals[(130 - (n)) % 8],Vals[(128 - (n)) % 8])

//t1 calc when W is already calculated
#define t1(n) K[(n) % 64] + Vals[(135 - (n)) % 8] +  W[(n)] + s1(n) + ch(n)

//t1 calc which calculates W
#define t1W(n) K[(n) % 64] + Vals[(135 - (n)) % 8] +  W(n) + s1(n) + ch(n)

//Used for constant W Values (the compiler optimizes out zeros)
#define t1C(n) (K[(n) % 64]+ ConstW[(n)]) + Vals[(135 - (n)) % 8] + s1(n) + ch(n)

//t2 Calc
#define t2(n)  maj(n) + s0(n)

#define rotC(x,n) (x<<n | x >> (32-n))

//W calculation used for SHA round
#define W(n) (W[n] = P4(n) + P3(n) + P2(n) + P1(n))


//Partial W calculations (used for the begining where only some values are nonzero)
#define P1(n) ((rot(W[(n)-2],15u)^rot(W[(n)-2],13u)^((W[(n)-2])>>10U)))
#define P2(n) ((rot(W[(n)-15],25u)^rot(W[(n)-15],14u)^((W[(n)-15])>>3U)))
#define p1(x) ((rot(x,15u)^rot(x,13u)^((x)>>10U)))
#define p2(x) ((rot(x,25u)^rot(x,14u)^((x)>>3U)))
#define P3(n)  W[n-7]
#define P4(n)  W[n-16]

//Partial Calcs for constant W values
#define P1C(n) ((rotC(ConstW[(n)-2],15)^rotC(ConstW[(n)-2],13)^((ConstW[(n)-2])>>10U)))
#define P2C(n) ((rotC(ConstW[(n)-15],25)^rotC(ConstW[(n)-15],14)^((ConstW[(n)-15])>>3U)))
#define P3C(x)  ConstW[x-7]
#define P4C(x)  ConstW[x-16]

//SHA round with built in W calc
#define sharoundW(n) Barrier1(n);  Vals[(131 - (n)) % 8] += t1W(n); Vals[(135 - (n)) % 8] = t1W(n) + t2(n);  

//SHA round without W calc
#define sharound(n)  Barrier2(n); Vals[(131 - (n)) % 8] += t1(n); Vals[(135 - (n)) % 8] = t1(n) + t2(n);

//SHA round for constant W values
#define sharoundC(n)  Barrier2(n); Vals[(131 - (n)) % 8] += t1C(n); Vals[(135 - (n)) % 8] = t1C(n) + t2(n);

//The compiler is stupid... I put this in there only to stop the compiler from (de)optimizing the order
#define Barrier1(n) t1 = t1C((n+1))
#define Barrier2(n) t1 = t1C((n))

__kernel
//removed this to allow detection of invalid work size
//__attribute__((reqd_work_group_size(WORKSIZE, 1, 1)))
void search( const uint state0, const uint state1, const uint state2, const uint state3,
const uint state4, const uint state5, const uint state6, const uint state7,
const uint B1, const uint C1, const uint D1,
const uint F1, const uint G1, const uint H1,
const u base,
const uint W16, const uint W17,
const uint PreVal4, const uint PreVal0,
const uint PreW31, const uint PreW32,
const uint PreW19, const uint PreW20,
__global uint * output)
{

u W[124];
u Vals[8];

//Dummy Variable to prevent compiler from reordering between rounds
u t1;

W[16] = W16;
W[17] = W17;

#ifdef VECTORS8

//Modified from VECTORS4
W[3] = base + (uint)(get_local_id(0)) * 8u + (uint)(get_group_id(0)) * (WORKSIZE * 8u);
uint r = rot(W[3].s0,25u)^rot(W[3].s0,14u)^((W[3].s0)>>3U);
W[18] = PreW20 + (u){r, r ^ 0x2004000U, r ^ 0x4008000U, r ^ 0x600C000U, r ^ 0x8010000U, r ^ 0xA050000U, r ^ 0xC090000U, r ^ 0xE0D0000U};

#elif defined VECTORS4
//Less dependencies to get both the local id and group id and then add them
W[3] = base + (uint)(get_local_id(0)) * 4u + (uint)(get_group_id(0)) * (WORKSIZE * 4u);
uint r = rot(W[3].s0,25u)^rot(W[3].s0,14u)^((W[3].s0)>>3U);
//Since only the 2 LSB is opposite between the nonces, we can save an instruction by flipping the 4 bits in W18 rather than the 1 bit in W3
W[18] = PreW20 + (u){r, r ^ 0x2004000U, r ^ 0x4008000U, r ^ 0x600C000U};

#elif defined VECTORS
W[3] = base + (uint)(get_local_id(0)) * 2u + (uint)(get_group_id(0)) * (WORKSIZE * 2u);
uint r = rot(W[3].s0,25u)^rot(W[3].s0,14u)^((W[3].s0)>>3U);
W[18] = PreW20 + (u){r, r ^ 0x2004000U};

#else
W[3] = base + get_local_id(0) + get_group_id(0) * (WORKSIZE);
u r = rot(W[3],25u)^rot(W[3],14u)^((W[3])>>3U);
W[18] = PreW20 + r;
#endif

//the order of the W calcs and Rounds is like this because the compiler needs help finding how to order the instructions


//Vals[0]=state0;
Vals[0] = PreVal0 + W[3];
Vals[1]=B1;
Vals[2]=C1;
Vals[3]=D1;
//Vals[4]=PreVal4;
Vals[4] = PreVal4 + W[3];
Vals[5]=F1;
Vals[6]=G1;
Vals[7]=H1;

sharoundC(4);
W[19] = PreW19 + W[3];
sharoundC(5);
W[20] = P1(20) + P4C(20);
sharoundC(6);
W[21] = P1(21);
sharoundC(7);
W[22] = P1(22) + P3C(22);
sharoundC(8);
W[23] = W[16] + P1(23);
sharoundC(9);
W[24] = W[17] + P1(24);
sharoundC(10);
W[25] = P1(25) + P3(25);
W[26] = P1(26) + P3(26);
sharoundC(11);
W[27] = P1(27) + P3(27);
W[28] = P1(28) + P3(28);
sharoundC(12);
W[29] = P1(29) + P3(29);
sharoundC(13);
W[30] = P1(30) + P2C(30) + P3(30);
W[31] = P1(31) + P3(31) + PreW31;
sharoundC(14);
W[32] = P1(32) + P3(32) + PreW32;
sharoundC(15);
sharound(16);
sharound(17);
sharound(18);
sharound(19);
sharound(20);
sharound(21);
sharound(22);
sharound(23);
sharound(24);
sharound(25);
sharound(26);
sharound(27);
sharound(28);
sharound(29);
sharound(30);
sharound(31);
sharound(32);
sharoundW(33);
sharoundW(34);
sharoundW(35);
sharoundW(36);
sharoundW(37);
sharoundW(38);
sharoundW(39);
sharoundW(40);
sharoundW(41);
sharoundW(42);
sharoundW(43);
sharoundW(44);
sharoundW(45);
sharoundW(46);
sharoundW(47);
sharoundW(48);
sharoundW(49);
sharoundW(50);
sharoundW(51);
sharoundW(52);
sharoundW(53);
sharoundW(54);
sharoundW(55);
sharoundW(56);
sharoundW(57);
sharoundW(58);
sharoundW(59);
sharoundW(60);
sharoundW(61);
sharoundW(62);
sharoundW(63);

W[64]=state0+Vals[0];
W[65]=state1+Vals[1];
W[66]=state2+Vals[2];
W[67]=state3+Vals[3];
W[68]=state4+Vals[4];
W[69]=state5+Vals[5];
W[70]=state6+Vals[6];
W[71]=state7+Vals[7];

Vals[0]=H[0];
Vals[1]=H[1];
Vals[2]=H[2];
// Vals[3]=H[3];
Vals[3] = 0xa54ff53aU + (0xb0edbdd0U + K[0]) +  W[64];
Vals[4]=H[4];
Vals[5]=H[5];
Vals[6]=H[6];
// Vals[7]=H[7];
Vals[7] = 0x08909ae5U + (0xb0edbdd0U + K[0]) +  W[64];

//const u Temp = (0xb0edbdd0U + K[0]) +  W[64];



//#define P124(n) P1(n) + P2(n) + P4(n)

W[80] = + P2(80) + P4(80);
sharound(65);
W[81] = P1C(81) + P2(81) + P4(81);
sharound(66);
W[82] = P1(82) + P2(82) + P4(82);
sharound(67);
W[83] = P1(83) + P2(83) + P4(83);
sharound(68);
W[84] = P1(84) + P2(84) + P4(84);
sharound(69);
W[85] = P1(85) + P2(85) + P4(85);
sharound(70);
W[86] = P1(86) + P2(86) + P3C(86) + P4(86);
sharound(71);
W[87] = P1(87) + P2C(87) + P3(87) + P4(87);
sharoundC(72);
W[88] =   P1(88) + P3(88) + P4C(88);
sharoundC(73);
W[89] = P1(89) + P3(89);
sharoundC(74);
W[90] = P1(90) + P3(90);
sharoundC(75);
W[91] = P1(91) + P3(91);
sharoundC(76);
W[92] = P1(92) + P3(92);
sharoundC(77);
W[93] = P1(93) + P3(93);
W[94] = P1(94) + P2C(94) + P3(94);
sharoundC(78);
W[95] = P1(95) + P2(95) + P3(95) + P4C(95);
sharoundC(79);
sharound(80);
sharound(81);
sharound(82);
sharound(83);
sharound(84);
sharound(85);
sharound(86);
sharound(87);
sharound(88);
sharound(89);
sharound(90);
sharound(91);
sharound(92);
sharound(93);
sharound(94);
sharound(95);
sharoundW(96);
sharoundW(97);
sharoundW(98);
sharoundW(99);
sharoundW(100);
sharoundW(101);
sharoundW(102);
sharoundW(103);
sharoundW(104);
sharoundW(105);
sharoundW(106);
sharoundW(107);
sharoundW(108);
sharoundW(109);
sharoundW(110);
sharoundW(111);
sharoundW(112);
sharoundW(113);
sharoundW(114);
sharoundW(115);
sharoundW(116);
sharoundW(117);
sharoundW(118);
sharoundW(119);
sharoundW(120);
sharoundW(121);
sharoundW(122);

u v = W[117] + W[108] + Vals[3] + Vals[7] + P2(124) + P1(124) + Ch((Vals[0] + Vals[4]) + (K[59] + W(123)) + s1(123)+ ch(123),Vals[1],Vals[2]);
u g = -(K[60] + H[7]) - S1((Vals[0] + Vals[4]) + (K[59] + W(123))  + s1(123)+ ch(123));

uint nonce = 0;

#ifdef VECTORS8
if (v.s0 == g.s0)
{
nonce = W[3].s0;
}
if (v.s1 == g.s1)
{
nonce = W[3].s1;
}
if (v.s2 == g.s2)
{
nonce = W[3].s2;
}
if (v.s3 == g.s3)
{
nonce = W[3].s3;
}
if (v.s4 == g.s4)
{
nonce = W[3].s4;
}
if (v.s5 == g.s5)
{
nonce = W[3].s5;
}
if (v.s6 == g.s6)
{
nonce = W[3].s6;
}
if (v.s7 == g.s7)
{
nonce = W[3].s7;
}
#elif defined VECTORS4
if (v.s0 == g.s0)
{
nonce = W[3].s0;
}
if (v.s1 == g.s1)
{
nonce = W[3].s1;
}
if (v.s2 == g.s2)
{
nonce = W[3].s2;
}
if (v.s3 == g.s3)
{
nonce = W[3].s3;
}
#elif defined VECTORS
if (v.s0 == g.s0)
{
nonce = W[3].s0;
}
if (v.s1 == g.s1)
{
nonce = W[3].s1;
}
#else
if (v == g)
{
nonce = W[3];
}
#endif
if(nonce)
{
//Faster to shift the nonce by 2 due to 4-DWORD addressing and does not add more collisions
output[WORKSIZE] = nonce;
output[get_local_id(0)] = nonce;
}
}


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Bananington on February 06, 2012, 11:48:50 PM
Could we get a list of all accepted options?
Kernel selection
Worksize=
Vectors, Vectors4, Vectors8, Vectors16
etc.

The Phoenix 2 core itself recognizes (not an exhaustive list):
Code:
# [cl:0:0] autoconfigure # Allow the kernel to choose its own configuration variables?
# [cl:0:0] disabled # Prevent mining on this device?
# [cl:0:0] kernel # Can be used to manually choose a kernel to mine on.
# [cl:0:0] start_undetected # Start even if autodetect doesn't find it?
# [general] autodetect # A list of rules for what devices to autodetect.
# [general] backend # The URL to mine on in the backend.
# [general] logfile # Set this option to log to a file.
# [general] queuedelay # Advanced - ???
# [general] queuesize # Advanced - ???
# [general] ratesamples # Advanced - number of samples to average for rate reporting
# [general] statusinterval # Advanced - how long to delay between statusbar updates
# [general] verbose # Enable verbose mode? (Shows debug messages)
# [web] bind # Bind the web/RPC server to a specific IP
# [web] disabled # Disable the webserver altogether?
# [web] logbuffer # Advanced - how many logs to remember in the getlogs() RPC call
# [web] password # The password necessary for web/RPC login (username is ignored)
# [web] port # What port should the web/RPC server listen on?
# [web] root # Advanced - The root directory for the webserver.

The phatk2/opencl kernels recognize:
Code:
# [cl:0:0] vectors # Enable two-way vectors?
# [cl:0:0] vectors4 # Enable four-way vectors?
# [cl:0:0] fastloop # Advanced - fastloop optimization for low aggressions
# [cl:0:0] aggression # Controls how hard Phoenix 2 hits the hardware
# [cl:0:0] worksize # Advanced - controls size of individual executions
# [cl:0:0] bfi_int # Enable BFI_INT optimization for Radeon cards that support it

[cl:0:0]
autoconfigure = False
BFI_INT VECTORS4 WORKSIZE=64

What's wrong with this portion that it's not giving me the correct settings?

Try:
Code:
[cl:0:0]
autoconfigure = false # Not actually needed since autoconfiguration disables by default when you supply your own args
BFI_INT = true # Also the boolean options aren't case sensitive.
VECTORS4 = true
WORKSIZE = 64

I believe this should be edited into the first post for the late joiners. :)


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: Bananington on February 06, 2012, 11:59:03 PM
How high can I turn up the aggression? Is 12 the max?


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: d3m0n1q_733rz on February 07, 2012, 12:29:36 AM
Alright, I have a register spill somewhere in here...can someone find it for me?  I'm using 8 vectors to make better use of the 16 available to the HD79xx cards.  But the code itself isn't made to handle it.  I just can't figure out what part needs to be changed to make it capable.   :-[

Code:
// This file is in the public domain

#ifdef VECTORS8
typedef uint8 u;
#elif defined VECTORS4
typedef uint4 u;
#elif defined VECTORS
typedef uint2 u;
#else
typedef uint u;
#endif

__constant uint K[64] = {
0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
};

__constant uint ConstW[128] = {
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x80000000U, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000280U,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,

0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x80000000U, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000100U,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
};

__constant uint H[8] = {
0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19
};

#ifdef BITALIGN
#pragma OPENCL EXTENSION cl_amd_media_ops : enable
#define rot(x, y) amd_bitalign(x, x, (uint)(32 - y))
#else
#define rot(x, y) rotate(x, (uint)y)
#endif

// Some AMD devices have the BFI_INT opcode, which behaves exactly like the
// SHA-256 Ch function, but provides it in exactly one instruction. If
// detected, use it for Ch. Otherwise, use bitselect() for Ch.

#ifdef BFI_INT
// Well, slight problem... It turns out BFI_INT isn't actually exposed to
// OpenCL (or CAL IL for that matter) in any way. However, there is
// a similar instruction, BYTE_ALIGN_INT, which is exposed to OpenCL via
// amd_bytealign, takes the same inputs, and provides the same output.
// We can use that as a placeholder for BFI_INT and have the application
// patch it after compilation.

// This is the BFI_INT function
#define Ch(x, y, z) amd_bytealign(x,y,z)
// Ma can also be implemented in terms of BFI_INT...
#define Ma(z, x, y) amd_bytealign(z^x,y,x)
#else
#define Ch(x, y, z) bitselect(z,y,x)
#define Ma(x, y, z) bitselect(x,y,(z^x))
#endif

//Various intermediate calculations for each SHA round
#define s0(n) (S0(Vals[(128 - (n)) % 8]))
#define S0(n) (rot(n, 30u)^rot(n, 19u)^rot(n,10u))

#define s1(n) (S1(Vals[(132 - (n)) % 8]))
#define S1(n) (rot(n, 26u)^rot(n, 21u)^rot(n, 7u))

#define ch(n) Ch(Vals[(132 - (n)) % 8],Vals[(133 - (n)) % 8],Vals[(134 - (n)) % 8])
#define maj(n) Ma(Vals[(129 - (n)) % 8],Vals[(130 - (n)) % 8],Vals[(128 - (n)) % 8])

//t1 calc when W is already calculated
#define t1(n) K[(n) % 64] + Vals[(135 - (n)) % 8] +  W[(n)] + s1(n) + ch(n)

//t1 calc which calculates W
#define t1W(n) K[(n) % 64] + Vals[(135 - (n)) % 8] +  W(n) + s1(n) + ch(n)

//Used for constant W Values (the compiler optimizes out zeros)
#define t1C(n) (K[(n) % 64]+ ConstW[(n)]) + Vals[(135 - (n)) % 8] + s1(n) + ch(n)

//t2 Calc
#define t2(n)  maj(n) + s0(n)

#define rotC(x,n) (x<<n | x >> (32-n))

//W calculation used for SHA round
#define W(n) (W[n] = P4(n) + P3(n) + P2(n) + P1(n))


//Partial W calculations (used for the begining where only some values are nonzero)
#define P1(n) ((rot(W[(n)-2],15u)^rot(W[(n)-2],13u)^((W[(n)-2])>>10U)))
#define P2(n) ((rot(W[(n)-15],25u)^rot(W[(n)-15],14u)^((W[(n)-15])>>3U)))
#define p1(x) ((rot(x,15u)^rot(x,13u)^((x)>>10U)))
#define p2(x) ((rot(x,25u)^rot(x,14u)^((x)>>3U)))
#define P3(n)  W[n-7]
#define P4(n)  W[n-16]

//Partial Calcs for constant W values
#define P1C(n) ((rotC(ConstW[(n)-2],15)^rotC(ConstW[(n)-2],13)^((ConstW[(n)-2])>>10U)))
#define P2C(n) ((rotC(ConstW[(n)-15],25)^rotC(ConstW[(n)-15],14)^((ConstW[(n)-15])>>3U)))
#define P3C(x)  ConstW[x-7]
#define P4C(x)  ConstW[x-16]

//SHA round with built in W calc
#define sharoundW(n) Barrier1(n);  Vals[(131 - (n)) % 8] += t1W(n); Vals[(135 - (n)) % 8] = t1W(n) + t2(n);  

//SHA round without W calc
#define sharound(n)  Barrier2(n); Vals[(131 - (n)) % 8] += t1(n); Vals[(135 - (n)) % 8] = t1(n) + t2(n);

//SHA round for constant W values
#define sharoundC(n)  Barrier2(n); Vals[(131 - (n)) % 8] += t1C(n); Vals[(135 - (n)) % 8] = t1C(n) + t2(n);

//The compiler is stupid... I put this in there only to stop the compiler from (de)optimizing the order
#define Barrier1(n) t1 = t1C((n+1))
#define Barrier2(n) t1 = t1C((n))

__kernel
//removed this to allow detection of invalid work size
//__attribute__((reqd_work_group_size(WORKSIZE, 1, 1)))
void search( const uint state0, const uint state1, const uint state2, const uint state3,
const uint state4, const uint state5, const uint state6, const uint state7,
const uint B1, const uint C1, const uint D1,
const uint F1, const uint G1, const uint H1,
const u base,
const uint W16, const uint W17,
const uint PreVal4, const uint PreVal0,
const uint PreW31, const uint PreW32,
const uint PreW19, const uint PreW20,
__global uint * output)
{

u W[124];
u Vals[8];

//Dummy Variable to prevent compiler from reordering between rounds
u t1;

W[16] = W16;
W[17] = W17;

#ifdef VECTORS8

//Modified from VECTORS4
W[3] = base + (uint)(get_local_id(0)) * 8u + (uint)(get_group_id(0)) * (WORKSIZE * 8u);
uint r = rot(W[3].s0,25u)^rot(W[3].s0,14u)^((W[3].s0)>>3U);
W[18] = PreW20 + (u){r, r ^ 0x2004000U, r ^ 0x4008000U, r ^ 0x600C000U, r ^ 0x8010000U, r ^ 0xA050000U, r ^ 0xC090000U, r ^ 0xE0D0000U};

#elif defined VECTORS4
//Less dependencies to get both the local id and group id and then add them
W[3] = base + (uint)(get_local_id(0)) * 4u + (uint)(get_group_id(0)) * (WORKSIZE * 4u);
uint r = rot(W[3].s0,25u)^rot(W[3].s0,14u)^((W[3].s0)>>3U);
//Since only the 2 LSB is opposite between the nonces, we can save an instruction by flipping the 4 bits in W18 rather than the 1 bit in W3
W[18] = PreW20 + (u){r, r ^ 0x2004000U, r ^ 0x4008000U, r ^ 0x600C000U};

#elif defined VECTORS
W[3] = base + (uint)(get_local_id(0)) * 2u + (uint)(get_group_id(0)) * (WORKSIZE * 2u);
uint r = rot(W[3].s0,25u)^rot(W[3].s0,14u)^((W[3].s0)>>3U);
W[18] = PreW20 + (u){r, r ^ 0x2004000U};

#else
W[3] = base + get_local_id(0) + get_group_id(0) * (WORKSIZE);
u r = rot(W[3],25u)^rot(W[3],14u)^((W[3])>>3U);
W[18] = PreW20 + r;
#endif

//the order of the W calcs and Rounds is like this because the compiler needs help finding how to order the instructions


//Vals[0]=state0;
Vals[0] = PreVal0 + W[3];
Vals[1]=B1;
Vals[2]=C1;
Vals[3]=D1;
//Vals[4]=PreVal4;
Vals[4] = PreVal4 + W[3];
Vals[5]=F1;
Vals[6]=G1;
Vals[7]=H1;

sharoundC(4);
W[19] = PreW19 + W[3];
sharoundC(5);
W[20] = P1(20) + P4C(20);
sharoundC(6);
W[21] = P1(21);
sharoundC(7);
W[22] = P1(22) + P3C(22);
sharoundC(8);
W[23] = W[16] + P1(23);
sharoundC(9);
W[24] = W[17] + P1(24);
sharoundC(10);
W[25] = P1(25) + P3(25);
W[26] = P1(26) + P3(26);
sharoundC(11);
W[27] = P1(27) + P3(27);
W[28] = P1(28) + P3(28);
sharoundC(12);
W[29] = P1(29) + P3(29);
sharoundC(13);
W[30] = P1(30) + P2C(30) + P3(30);
W[31] = P1(31) + P3(31) + PreW31;
sharoundC(14);
W[32] = P1(32) + P3(32) + PreW32;
sharoundC(15);
sharound(16);
sharound(17);
sharound(18);
sharound(19);
sharound(20);
sharound(21);
sharound(22);
sharound(23);
sharound(24);
sharound(25);
sharound(26);
sharound(27);
sharound(28);
sharound(29);
sharound(30);
sharound(31);
sharound(32);
sharoundW(33);
sharoundW(34);
sharoundW(35);
sharoundW(36);
sharoundW(37);
sharoundW(38);
sharoundW(39);
sharoundW(40);
sharoundW(41);
sharoundW(42);
sharoundW(43);
sharoundW(44);
sharoundW(45);
sharoundW(46);
sharoundW(47);
sharoundW(48);
sharoundW(49);
sharoundW(50);
sharoundW(51);
sharoundW(52);
sharoundW(53);
sharoundW(54);
sharoundW(55);
sharoundW(56);
sharoundW(57);
sharoundW(58);
sharoundW(59);
sharoundW(60);
sharoundW(61);
sharoundW(62);
sharoundW(63);

W[64]=state0+Vals[0];
W[65]=state1+Vals[1];
W[66]=state2+Vals[2];
W[67]=state3+Vals[3];
W[68]=state4+Vals[4];
W[69]=state5+Vals[5];
W[70]=state6+Vals[6];
W[71]=state7+Vals[7];

Vals[0]=H[0];
Vals[1]=H[1];
Vals[2]=H[2];
// Vals[3]=H[3];
Vals[3] = 0xa54ff53aU + (0xb0edbdd0U + K[0]) +  W[64];
Vals[4]=H[4];
Vals[5]=H[5];
Vals[6]=H[6];
// Vals[7]=H[7];
Vals[7] = 0x08909ae5U + (0xb0edbdd0U + K[0]) +  W[64];

//const u Temp = (0xb0edbdd0U + K[0]) +  W[64];



//#define P124(n) P1(n) + P2(n) + P4(n)

W[80] = + P2(80) + P4(80);
sharound(65);
W[81] = P1C(81) + P2(81) + P4(81);
sharound(66);
W[82] = P1(82) + P2(82) + P4(82);
sharound(67);
W[83] = P1(83) + P2(83) + P4(83);
sharound(68);
W[84] = P1(84) + P2(84) + P4(84);
sharound(69);
W[85] = P1(85) + P2(85) + P4(85);
sharound(70);
W[86] = P1(86) + P2(86) + P3C(86) + P4(86);
sharound(71);
W[87] = P1(87) + P2C(87) + P3(87) + P4(87);
sharoundC(72);
W[88] =   P1(88) + P3(88) + P4C(88);
sharoundC(73);
W[89] = P1(89) + P3(89);
sharoundC(74);
W[90] = P1(90) + P3(90);
sharoundC(75);
W[91] = P1(91) + P3(91);
sharoundC(76);
W[92] = P1(92) + P3(92);
sharoundC(77);
W[93] = P1(93) + P3(93);
W[94] = P1(94) + P2C(94) + P3(94);
sharoundC(78);
W[95] = P1(95) + P2(95) + P3(95) + P4C(95);
sharoundC(79);
sharound(80);
sharound(81);
sharound(82);
sharound(83);
sharound(84);
sharound(85);
sharound(86);
sharound(87);
sharound(88);
sharound(89);
sharound(90);
sharound(91);
sharound(92);
sharound(93);
sharound(94);
sharound(95);
sharoundW(96);
sharoundW(97);
sharoundW(98);
sharoundW(99);
sharoundW(100);
sharoundW(101);
sharoundW(102);
sharoundW(103);
sharoundW(104);
sharoundW(105);
sharoundW(106);
sharoundW(107);
sharoundW(108);
sharoundW(109);
sharoundW(110);
sharoundW(111);
sharoundW(112);
sharoundW(113);
sharoundW(114);
sharoundW(115);
sharoundW(116);
sharoundW(117);
sharoundW(118);
sharoundW(119);
sharoundW(120);
sharoundW(121);
sharoundW(122);

u v = W[117] + W[108] + Vals[3] + Vals[7] + P2(124) + P1(124) + Ch((Vals[0] + Vals[4]) + (K[59] + W(123)) + s1(123)+ ch(123),Vals[1],Vals[2]);
u g = -(K[60] + H[7]) - S1((Vals[0] + Vals[4]) + (K[59] + W(123))  + s1(123)+ ch(123));

uint nonce = 0;

#ifdef VECTORS8
if (v.s0 == g.s0)
{
nonce = W[3].s0;
}
if (v.s1 == g.s1)
{
nonce = W[3].s1;
}
if (v.s2 == g.s2)
{
nonce = W[3].s2;
}
if (v.s3 == g.s3)
{
nonce = W[3].s3;
}
if (v.s4 == g.s4)
{
nonce = W[3].s4;
}
if (v.s5 == g.s5)
{
nonce = W[3].s5;
}
if (v.s6 == g.s6)
{
nonce = W[3].s6;
}
if (v.s7 == g.s7)
{
nonce = W[3].s7;
}
#elif defined VECTORS4
if (v.s0 == g.s0)
{
nonce = W[3].s0;
}
if (v.s1 == g.s1)
{
nonce = W[3].s1;
}
if (v.s2 == g.s2)
{
nonce = W[3].s2;
}
if (v.s3 == g.s3)
{
nonce = W[3].s3;
}
#elif defined VECTORS
if (v.s0 == g.s0)
{
nonce = W[3].s0;
}
if (v.s1 == g.s1)
{
nonce = W[3].s1;
}
#else
if (v == g)
{
nonce = W[3];
}
#endif
if(nonce)
{
//Faster to shift the nonce by 2 due to 4-DWORD addressing and does not add more collisions
output[WORKSIZE] = nonce;
output[get_local_id(0)] = nonce;
}
}
I think the problem's in this line:  W[18] = PreW20 + (u){r, r ^ 0x2004000U, r ^ 0x4008000U, r ^ 0x600C000U, r ^ 0x8010000U, r ^ 0xA050000U, r ^ 0xC090000U, r ^ 0xE0D0000U};
I probably used the wrong values on the second half.
Edit:  Bingo!  But still have a spill...


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: CFSworks on February 07, 2012, 05:11:55 AM
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 ?

While both of these features are really nice, there is no easy way to interface with these functions on the card through OpenCL. We can do it, and I've asked jedi95 about it. His stance on the issue is pretty much what lodcrappo said:
please no.  don't turn phoenix into the monstrosity of some other miners.  it's simplicity is it's beauty.

do one thing, and do it well.

when you throw everything possible into one program, you end up with too many compromises.

So, we're definitely not adding GPU management features to the Phoenix 2 core.

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

Thank you !

It's important to keep in mind that cgminer and Phoenix are alternatives, not competitors. We're both on the same side here. If you like cgminer better, please, use it! :) Phoenix's purpose is to do things differently for those that don't prefer the way cgminer operates. (And, Python BS? I'm assuming you mean the dependencies you have to install to get Phoenix operational, since I don't see how choice of language affects the end-user, especially when the core was written with speed in mind.)


I 100% agree and support this decision. Remember the KISS principle. If you need OC stick to AMD API thing.

Adding OC and fan management is very tempting, I must admit. A thought occurs to me: What if we renamed the "kernels" directory to "modules" or the like, and allowed non-kernel modules to be loaded into Phoenix as well? This allows a third party to easily develop a complete GPU management subsystem that integrates into Phoenix while still keeping the core slim and fast for those who prefer to do OC themselves.


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: lodcrappo on February 07, 2012, 05:18:12 AM


Adding OC and fan management is very tempting, I must admit. A thought occurs to me: What if we renamed the "kernels" directory to "modules" or the like, and allowed non-kernel modules to be loaded into Phoenix as well? This allows a third party to easily develop a complete GPU management subsystem that integrates into Phoenix while still keeping the core slim and fast for those who prefer to do OC themselves.

as the developer of a popular mining farm management system that uses "best of breed" tools for each function, including phoenix for the mining client part, I think this is a great idea.  Currently we have to hack the management code into each phoenix release, which isn't a big deal but having a standard way to interface would be much nicer.


Title: Re: Phoenix 2 beta discussion
Post by: wind on February 07, 2012, 10:49:13 AM
is it possible to add commandline parameters like phoenix 1.x does?


Title: Re: Phoenix 2 beta discussion
Post by: echris1 on February 07, 2012, 12:50:21 PM
Just switched all my miners to this after a drastic drop in cgminer performance (something to do with SDK, not sure) 

Working great on my 2x6770, 6850 and 5770, back at max after a bit of tweaking.

I was just wondering how to add a backup pool to the conf file?

Keep up the good work!


Title: Re: Sorry, Phoenix 1.8 will not be released
Post by: HendrikJan on February 07, 2012, 02:59:18 PM
Adding OC and fan management is very tempting, I must admit. A thought occurs to me: What if we renamed the "kernels" directory to "modules" or the like, and allowed non-kernel modules to be loaded into Phoenix as well? This allows a third party to easily develop a complete GPU management subsystem that integrates into Phoenix while still keeping the core slim and fast for those who prefer to do OC themselves.

It could be a nice way to get the best of both worlds.

But i still get less Mh/s with this 2.0 version.
What could be the difference?
Should i get the same result or does this version still need some tweaking?


Title: Re: Phoenix 2 beta discussion - Feedback
Post by: Diapolo on February 07, 2012, 03:47:42 PM
Code:
[general]
autodetect = +cl
backend = XYZ
verbose = true

[cl:0:0]
kernel = diakgcn
aggression = 12
vectors2 = true
vectors4 = false
vectors8 = false
worksize = 256

[cl:0:1]
disabled = true

[cl:0:2]
disabled = true

[web]
disabled = true

Above config generates "Detected [cl:0:0]: [Tahiti 0] using opencl (rating 2)", which I don't understand. Shouldn't it simply use the kernel specified and tell that autodetect had been overridden by own settings. Another thing I don't understand is, why getDevice() and autodetect() reside in kernels\opencl\__init__.py I dislike the idea, that these functions are derived from there, because opencl is simply another kernel folder. I think they should be placed somewhere else (have no good idea currently, but perhaps in PhoenixCore.py).

The supplied phatk2 version uses stuff in opencl\__init__.py, too via "opencl = sys.modules['opencl']", which seems sort of not ideal. I think every kernel should specify his own options and stuff, even if they are the same. Your idea was perhaps to edit only one place, if you add new changes, but for addon kernels like diakgcn I really have to specify my own options, which I would promote as a rule for all supplied or addon kernels to be better structured and to be independend of the opencl kernel folder. What do you think?

Another small change I would suggest for analyzeDevice() is your CPU detection code, which could be replaced with:
Code:
# Check if the device is a CPU
if device.get_info(cl.device_info.TYPE) == cl.device_type.CPU:
return (1, {'name': name, 'aggression': 0}, [devid, 'cpu:0'])

Dia


Title: Re: Phoenix 2 beta discussion
Post by: Schwede65 on February 07, 2012, 05:44:43 PM
great work... just tested 1.75... and now only one process for all gpu's

Question of setting the back-up-pool:

beginning of phoenix.cfg:

[general]
verbose = True
autodetect = +cl -cpu
backend = http: 123:45@67.89.0123:8332/ # URL format is exactly as it was in Phoenix 1
backup = http:  456:78@90.12.0123:8332/

is that correctly done?



Title: Re: Phoenix 2 beta discussion
Post by: d3m0n1q_733rz on February 07, 2012, 07:26:38 PM
Think you could add the ability to use plugins?  That might shut-up some of the people wanting more functions like overclocking, slowing hash rates based on core temps, restarting of crashed GPUs, pausing GPUs, etc. by letting them code things their self.  Just push P for plugins and start configuring away or access the config file for the plugin directly to change settings.  Seems like a good solution.


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 07, 2012, 09:23:38 PM
great work... just tested 1.75... and now only one process for all gpu's

Question of setting the back-up-pool:

beginning of phoenix.cfg:

[general]
verbose = True
autodetect = +cl -cpu
backend = http: 123:45@67.89.0123:8332/ # URL format is exactly as it was in Phoenix 1
backup = http:  456:78@90.12.0123:8332/

is that correctly done?



there is no backup pool support (atm)


Title: Re: Phoenix 2 beta discussion - Feedback
Post by: jedi95 on February 08, 2012, 02:33:32 AM
Above config generates "Detected [cl:0:0]: [Tahiti 0] using opencl (rating 2)", which I don't understand. Shouldn't it simply use the kernel specified and tell that autodetect had been overridden by own settings.

That's because you still have autodetect = +cl in the config file. Any devices with specific settings defined in the config file will use those instead of autodetect. The autodetect messages are currently displayed even if the settings are overridden by the config file. This will be clarified in a future release by either hiding the autodetect message or changing the message to indicate that the user-defined settings were used.

Another thing I don't understand is, why getDevice() and autodetect() reside in kernels\opencl\__init__.py I dislike the idea, that these functions are derived from there, because opencl is simply another kernel folder. I think they should be placed somewhere else (have no good idea currently, but perhaps in PhoenixCore.py).

The reason we have the device detection code at the kernel level is so that it can support any type of device. For example, the current FPGA miners don't have a standard API, which makes including this functionality in the Phoenix core a bad idea. We would have to add support for new devices into the Phoenix core. By doing these functions at the kernel level, it allows other developers to support new hardware with no changes to Phoenix itself.

The supplied phatk2 version uses stuff in opencl\__init__.py, too via "opencl = sys.modules['opencl']", which seems sort of not ideal. I think every kernel should specify his own options and stuff, even if they are the same. Your idea was perhaps to edit only one place, if you add new changes, but for addon kernels like diakgcn I really have to specify my own options, which I would promote as a rule for all supplied or addon kernels to be better structured and to be independend of the opencl kernel folder. What do you think?

Using functions from opencl for other kernels isn't required. This is simply how we decided to implement the supplied version of phatk2. Kernels DO NOT need to be implemented in this way.

Another small change I would suggest for analyzeDevice() is your CPU detection code, which could be replaced with:
Code:
# Check if the device is a CPU
if device.get_info(cl.device_info.TYPE) == cl.device_type.CPU:
return (1, {'name': name, 'aggression': 0}, [devid, 'cpu:0'])

Thanks for this code, I will modify opencl/phatk2 to use this method of detecting CPUs.


Title: Re: Phoenix 2 beta discussion
Post by: baby_ghost on February 08, 2012, 05:16:33 AM
Here is my phoenix.cfg, may I wrong on other sections? Miner speed lower than Phoenix 1.7.5
Code:
[general]
verbose = True
autodetect = +cl -cpu # The rightmost parameter takes precedence. This enables all OpenCL devices, except those that are CPUs.
backend = http://vinhpk.06:thunganhi@api.bitcoin.cz:8332/ # URL format is exactly as it was in Phoenix 1

[web]
password = rpc_password # Set an RPC password to keep people from messing with your miners.

# If you want to configure miners yourself, edit and uncomment this section:
#[cl:0:0] # Or whatever ID you want to configure.
#autoconfigure = True # Do you still want autoconfiguration?
#disabled = False # Do you want to disable the miner?
#bfi_int = True    # Any other kernel options...
#vectors = False # can go into this section.
phatk2 = True
VECTORS = True
BFI_INT = True
WORKSIZE = 256
AGGRESSION = 11
FASTLOOPS = false


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 08, 2012, 06:44:32 AM
#[cl:0:0] should be [cl:0:0], currently it's unused, because it's treated as a comment and is therefore simply ignored.

Dia


Title: Re: Phoenix 2 beta discussion
Post by: naz86 on February 08, 2012, 08:15:58 AM
Hi,

tryed this on my 5850 and 5830 catalyst 12.1/WIN7, the performance on the 5830 (960/300) [301MH/s] is great but on my 5850 (920/300) [309MH/s] it sucks normally i use poclbm because this is a productional system and i get 356MH/s! With
Code:
autoconfigure = true
i can reach 319MH/s.

should i change anything ?

Code:
[general]
verbose = True
autodetect = +cl -cpu
backend = http://lala:lala@lala.com:8332

[web]
password = rpc_password # Set an RPC password to keep people from messing with your miners.

[cl:1:0]
autoconfigure = false
BFI_INT = true
VECTORS4 = true
WORKSIZE = 64
AGRESSION = 12
FASTLOOPS = false
phatk2 = true


Title: Re: Phoenix 2 beta discussion
Post by: ZPK on February 08, 2012, 09:08:02 AM
7 x64 11.6
5850 950/300 395
5850 960/300 399

use this setting.

[cl:0:0]
autoconfigure = False
disabled = False
bfi_int = True
vectors = True
worksize=256
aggression=12


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 08, 2012, 10:30:27 AM
I see a lot of misuse of settings. phatk2 = true is not valid. autoconfigure is not needed at all when specifying device-specific settings, and so on. Here are some per-device settings I suggest under certain SDK's and certain GPU's. Aggressions are for dedicated miners. If you need to use the miner like a normal PC, suggest using an aggresion anywhere from 4-7, whichever is most comfortable for you. The settings go after each device which is denoted by something like [cl:1:1] where [cl:1:1] is the platform and [cl:1:1] is the device number.

SDK 2.1, Radeon 5xxx, 61xx-67xx, Underclocked memory
Code:
kernel = phatk2
AGGRESSION = 12
VECTORS = true
BFI_INT = true
WORKSIZE = 256

SDK 2.4/2.5, Radeon 5xxx, 6xxx, Underclocked memory
Code:
kernel = phatk2
AGGRESSION = 14
VECTORS = true
BFI_INT = true
WORKSIZE = 256

SDK 2.6, Radeon 5xxx, 6xxx, Normal memory (1GHz+)
Code:
kernel = phatk2
AGGRESSION = 14
VECTORS4 = true
BFI_INT = true
WORKSIZE = 64

If you are using 2.6 SDK with underclocked memory, I suggest installed 2.1 as well, or rolling back to 2.4/2.5 if you have 6800+'s in your miners as 2.6 is still garbage as far as speed goes. SDK 2.1 is still the fastest. 2.4/2.5 have the same speed as far as I can tell. The reduced aggression for SDK 2.1 is to reduce the chance that TDR will trigger and crash the miner (2.1 is highly aggressive in taking GPU time).

The opposite holds true; If you are stuck with high memory clocks, 2.6 is more efficient than 2.1-2.5.


Title: Re: Phoenix 2 beta discussion
Post by: mich on February 08, 2012, 10:34:54 AM
What I doing wrong? Ubuntu:
Code:
$:/usr/local/bin$ sudo phoenix.cfg
Traceback (most recent call last):
  File "/usr/local/bin/phoenix", line 9, in <module>
    load_entry_point('phoenix==2.0.0-rc1', 'console_scripts', 'phoenix')()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 305, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2245, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1955, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
ImportError: No module named phoenix
and phoenix does not starts (((


Title: Re: Phoenix 2 beta discussion
Post by: naz86 on February 08, 2012, 12:18:37 PM
I see a lot of misuse of settings. phatk2 = true is not valid. autoconfigure is not needed at all when specifying device-specific settings, and so on. Here are some per-device settings I suggest under certain SDK's and certain GPU's. Aggressions are for dedicated miners. If you need to use the miner like a normal PC, suggest using an aggresion anywhere from 4-7, whichever is most comfortable for you. The settings go after each device which is denoted by something like [cl:1:1] where [cl:1:1] is the platform and [cl:1:1] is the device number.

SDK 2.1, Radeon 5xxx, 61xx-67xx, Underclocked memory
Code:
kernel = phatk2
AGGRESSION = 12
VECTORS = true
BFI_INT = true
WORKSIZE = 256

SDK 2.4/2.5, Radeon 5xxx, 6xxx, Underclocked memory
Code:
kernel = phatk2
AGGRESSION = 14
VECTORS = true
BFI_INT = true
WORKSIZE = 256

SDK 2.6, Radeon 5xxx, 6xxx, Normal memory (1GHz+)
Code:
kernel = phatk2
AGGRESSION = 14
VECTORS4 = true
BFI_INT = true
WORKSIZE = 64

If you are using 2.6 SDK with underclocked memory, I suggest installed 2.1 as well, or rolling back to 2.4/2.5 if you have 6800+'s in your miners as 2.6 is still garbage as far as speed goes. SDK 2.1 is still the fastest. 2.4/2.5 have the same speed as far as I can tell. The reduced aggression for SDK 2.1 is to reduce the chance that TDR will trigger and crash the miner (2.1 is highly aggressive in taking GPU time).

The opposite holds true; If you are stuck with high memory clocks, 2.6 is more efficient than 2.1-2.5.


Thanks! i'll try... but my pool is down, going to report back!

btw: i like phoenix 2! for me phoenix is still the best miner pushing my cards to really good speed! it is also really easy to use (if you know the settings ;))

your post should be added to the first post to reduce questions!


[edit]

pushed each of my cards about 5-10MH/s each!!!!

phoenix is a turbo-biatch!
[/edit]


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 08, 2012, 03:45:02 PM
I know Phoenix 2 has to mature a while, but please fix that hashrate-display asap, because I simply can't tell if a kernel modification makes things faster or not, because of that amazing and really wrong values :D.

Dia


Title: Re: Phoenix 2 beta discussion
Post by: Bananington on February 08, 2012, 05:07:07 PM
I know Phoenix 2 has to mature a while, but please fix that hashrate-display asap, because I simply can't tell if a kernel modification makes things faster or not, because of that amazing and really wrong values :D.

Dia

True dat! lol.

Any ETA on an update for Phoenix 2 to fix this issue?


Title: Re: Phoenix 2 beta discussion
Post by: shackleford on February 08, 2012, 07:48:52 PM
I use a batch file to launch phoenix.exe so I can set the affinity to 1 core or else it will peg all 4 cores on my cpu. My question is can I also set what cfg file to use? I sync a btc working folder with wuala accross my mining machines and I would like to have cfg files for the diffrent machines and configs for like high speed and chill for desktop use through diffrent batch files.

Btw my dead shares in P2Pool has dropped to zero in the last 24hours after moving from 1.75 to 2.0


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 08, 2012, 07:55:30 PM
The current code in Git has been updated with a few fixes:

1. Hashrate display should be working correctly now. Please report back if it still doesn't work.
2. Updated opencl and phatk2 to use Diapolo's method of detecting if the device is a CPU.
3. Autodetect messages will no longer appear for devices which have a config manually defined.

The Windows binary has also been updated with these changes.


Title: Re: Phoenix 2 beta discussion
Post by: TurdHurdur on February 08, 2012, 09:17:18 PM
I'm getting what looks to be the same issue as mich, I'm on Debian 6:

Code:
name@hostname:~$ ./phoenix.cfg
Traceback (most recent call last):
  File "/usr/local/bin/phoenix", line 8, in <module>
    load_entry_point('phoenix==2.0.0-rc1', 'console_scripts', 'phoenix')()
  File "build/bdist.linux-i686/egg/pkg_resources.py", line 318, in load_entry_point
    def has_metadata(name):
  File "build/bdist.linux-i686/egg/pkg_resources.py", line 2221, in load_entry_point
    def __getattr__(self,attr):
  File "build/bdist.linux-i686/egg/pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
ImportError: No module named phoenix



Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 08, 2012, 09:58:48 PM
I'm getting what looks to be the same issue as mich, I'm on Debian 6:

Code:
name@hostname:~$ ./phoenix.cfg
Traceback (most recent call last):
  File "/usr/local/bin/phoenix", line 8, in <module>
    load_entry_point('phoenix==2.0.0-rc1', 'console_scripts', 'phoenix')()
  File "build/bdist.linux-i686/egg/pkg_resources.py", line 318, in load_entry_point
    def has_metadata(name):
  File "build/bdist.linux-i686/egg/pkg_resources.py", line 2221, in load_entry_point
    def __getattr__(self,attr):
  File "build/bdist.linux-i686/egg/pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
ImportError: No module named phoenix


I'll have CFSworks take a look at this later. In the mean time you can use phoenix by starting phoenix.py instead of executing the config file.


Title: Re: Phoenix 2 beta discussion
Post by: TurdHurdur on February 08, 2012, 10:09:30 PM
I'll have CFSworks take a look at this later. In the mean time you can use phoenix by starting phoenix.py instead of executing the config file.

Oh, I tried that, but this happened:

Code:
name@hostname:/usr/local/src/phoenix-2.0.0$ ./phoenix.py ~/phoenix.cfg
[02/08/2012 17:05:29] Welcome to Phoenix v2.0.0-rc1
[0 Khash/s] [0 Accepted] [0 Rejected] [DISCONNECTED]Traceback (most recent call last):
  File "./phoenix.py", line 37, in <module>
    main()
  File "./phoenix.py", line 32, in main
    pc.start()
  File "/usr/local/src/phoenix-2.0.0/phoenix2/core/PhoenixCore.py", line 78, in start
    self.discoverKernels()
  File "/usr/local/src/phoenix-2.0.0/phoenix2/core/PhoenixCore.py", line 109, in discoverKernels
    kernelModule = imp.load_module(name, file, filename, smt)
  File "/usr/local/src/phoenix-2.0.0/phoenix2/core/../kernels/phatk2/__init__.py", line 38, in <module>
    opencl = sys.modules['opencl']
KeyError: 'opencl'


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 08, 2012, 10:51:23 PM
The current code in Git has been updated with a few fixes:

1. Hashrate display should be working correctly now. Please report back if it still doesn't work.
2. Updated opencl and phatk2 to use Diapolo's method of detecting if the device is a CPU.
3. Autodetect messages will no longer appear for devices which have a config manually defined.

The Windows binary has also been updated with these changes.

Could you update the main post to point to the new updated phoenix2? I cant find the updated compiled windows version.


Title: Re: Phoenix 2 beta discussion
Post by: cyberlync on February 08, 2012, 11:42:18 PM
The current code in Git has been updated with a few fixes:

1. Hashrate display should be working correctly now. Please report back if it still doesn't work.
2. Updated opencl and phatk2 to use Diapolo's method of detecting if the device is a CPU.
3. Autodetect messages will no longer appear for devices which have a config manually defined.

The Windows binary has also been updated with these changes.

Could you update the main post to point to the new updated phoenix2? I cant find the updated compiled windows version.

As far as I can tell from a little research, jedi95 deleted the old phoenix-2.0.0.zip, and reuploaded a new file with the same name approx. 3 hrs ago, the link in the first post should work, and I'm guessing it's the updated binary.


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 09, 2012, 01:24:00 AM
The current code in Git has been updated with a few fixes:

1. Hashrate display should be working correctly now. Please report back if it still doesn't work.
2. Updated opencl and phatk2 to use Diapolo's method of detecting if the device is a CPU.
3. Autodetect messages will no longer appear for devices which have a config manually defined.

The Windows binary has also been updated with these changes.

Could you update the main post to point to the new updated phoenix2? I cant find the updated compiled windows version.

As far as I can tell from a little research, jedi95 deleted the old phoenix-2.0.0.zip, and reuploaded a new file with the same name approx. 3 hrs ago, the link in the first post should work, and I'm guessing it's the updated binary.

This is correct. Since I can't edit the first post it seemed like the most reasonable option.


Title: Re: Phoenix 2 beta discussion
Post by: d3m0n1q_733rz on February 09, 2012, 01:48:53 AM
Phatk2 GOFFSET Mod here!
https://bitcointalk.org/index.php?topic=63167.0


Title: Re: Phoenix 2 beta discussion
Post by: TurdHurdur on February 09, 2012, 01:52:12 AM
Oh, I tried that, but this happened:

Code:
name@hostname:/usr/local/src/phoenix-2.0.0$ ./phoenix.py ~/phoenix.cfg
[02/08/2012 17:05:29] Welcome to Phoenix v2.0.0-rc1
[0 Khash/s] [0 Accepted] [0 Rejected] [DISCONNECTED]Traceback (most recent call last):
  File "./phoenix.py", line 37, in <module>
    main()
  File "./phoenix.py", line 32, in main
    pc.start()
  File "/usr/local/src/phoenix-2.0.0/phoenix2/core/PhoenixCore.py", line 78, in start
    self.discoverKernels()
  File "/usr/local/src/phoenix-2.0.0/phoenix2/core/PhoenixCore.py", line 109, in discoverKernels
    kernelModule = imp.load_module(name, file, filename, smt)
  File "/usr/local/src/phoenix-2.0.0/phoenix2/core/../kernels/phatk2/__init__.py", line 38, in <module>
    opencl = sys.modules['opencl']
KeyError: 'opencl'

I fixed it myself, huzzah! in "phoenix2/core/PhoenixCore.py" line 105 change:

Code:
for name in os.listdir(kerndir):

to...

Code:
for name in sorted(os.listdir(kerndir)):

Because o has to come before p, opencl before phatk2. Maybe you should rename it 00-opencl. ;)


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 09, 2012, 01:53:42 AM
The current code in Git has been updated with a few fixes:

1. Hashrate display should be working correctly now. Please report back if it still doesn't work.
2. Updated opencl and phatk2 to use Diapolo's method of detecting if the device is a CPU.
3. Autodetect messages will no longer appear for devices which have a config manually defined.

The Windows binary has also been updated with these changes.

Could you update the main post to point to the new updated phoenix2? I cant find the updated compiled windows version.

As far as I can tell from a little research, jedi95 deleted the old phoenix-2.0.0.zip, and reuploaded a new file with the same name approx. 3 hrs ago, the link in the first post should work, and I'm guessing it's the updated binary.

This is correct. Since I can't edit the first post it seemed like the most reasonable option.

Are you sure you didn't upload the same exact files as what was up before? I redownloaded and the crc for the "old" phoenix and the "new" phoenix is the same. This also goes for the .zip file itself.

The CRC32 of my copy of phoenix.exe is 89B9736A. The copy inside the zip file I downloaded 20 seconds ago is also 89B9736A and I still get the hash rate bugging out.

Please fix.


Title: Re: Phoenix 2 beta discussion
Post by: deepceleron on February 09, 2012, 02:48:14 AM
Instead of the program creating a blank config file and aborting, that would be a good opportunity to run a little wizard questionnaire to set up the program:

[02/08/2012 18:44:39] Welcome to Phoenix v2.0.0-rc1
- I see this is the first time you've run Phoenix,
  please provide some information for your initial configuration:

Pool URL:
[if not detected in URL:]
Pool Port:
Pool Worker Username:
Pool Worker Password:

Available OpenCL processing devices:
    [[0]] Juniper
    [[1]] Juniper
    [[2]] Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz

Please input the device number(s) to use (Enter=use first GPU only):

Do you wish to autodetect the best settings (Y/N) (Enter=auto)?:

- Manual Configuration -

Available OpenCL software kernels:
    [[0]] opencl (default)
    [[1]] phatk2
    [[2]] diapolo

Please select the software kernel (Enter=default):

Available worksizes: 64, 128, 256
Please enter the OpenCL kernel worksize (Enter=autodetect):

Available vector sizes: 2, 4
Please enter the desired work vector size (Enter=autodetect):

Available aggression setting (work unit size): 1-14 (default 6)
Please enter the desired aggression (Enter=default):
 
- Thank you, parameters saved to configuration file phoenix.cfg!
[18:46:23] Connected to server
[18:46:23] Server gave new work; passing to WorkQueue
[18:46:23] New block (WorkQueue)


Title: Re: Phoenix 2 beta discussion
Post by: Bananington on February 09, 2012, 02:50:35 AM
Instead of the program creating a blank config file and aborting, that would be a good opportunity to run a little wizard questionnaire to set up the program:

"[02/08/2012 18:44:39] Welcome to Phoenix v2.0.0-rc1"
"I see this is the first time you've run Phoenix, please provide some information for your initial configuration:"

"Pool URL:"
[if not detected in URL:]
"Pool Port:"
"Pool Worker Username:"
"Pool Worker Password:"

"Available OpenCL processing devices:"
    [[0]] Juniper
    [[1]] Juniper
    [[2]] Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz

"Please input the number(s) of the devices to use (Enter= Use All):"

"Do you wish to autodetect the best settings (Y/N) (Enter=Auto)?:"

"- Manual Configuration -"

"Available OpenCL software kernels:"
    [[0]] opencl (default)
    [[1]] phatk2
    [[2]] diapolo

"Please select the software kernel (Enter=default):"

"Available worksizes: 64, 128, 256"
"Please enter the OpenCL kernel worksize (Enter=autodetect):"

"Available vector sizes: 2, 4"
"Please enter the desired work vector size (Enter=autodetect):"

"Available aggression setting (work unit size): 1-14 (default 6)"
"Please enter the desired aggression (Enter=default):"
 
"Thank you, parameters saved to configuration file phoenix.cfg!"
[18:46:23] Connected to server
[18:46:23] Server gave new work; passing to WorkQueue
[18:46:23] New block (WorkQueue)


I just blew my happiness load. +69


Title: Re: Phoenix 2 beta discussion
Post by: CFSworks on February 09, 2012, 03:27:43 AM
Instead of the program creating a blank config file and aborting, that would be a good opportunity to run a little wizard questionnaire to set up the program:

The plan is actually to tell the user to fire up a web browser and have PhoenixWeb run the first-time setup wizard. The only trouble is that PhoenixWeb still needs a lot of work before it's ready to be included in the standard Phoenix download. (Right now it only has enough there for a "real" web developer to pick it up and work on it...)


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 09, 2012, 03:32:01 AM
Instead of the program creating a blank config file and aborting, that would be a good opportunity to run a little wizard questionnaire to set up the program:

The plan is actually to tell the user to fire up a web browser and have PhoenixWeb run the first-time setup wizard. The only trouble is that PhoenixWeb still needs a lot of work before it's ready to be included in the standard Phoenix download. (Right now it only has enough there for a "real" web developer to pick it up and work on it...)

CFSWorks, could you please verify the crc of current windows build of phoenix.exe is 89B9736A ? I keep getting told that the windows build was updated but i'm just not seeing it because the "new" and "old" crc32s are identical, so I don't believe anything was updated/changed.


Title: Re: Phoenix 2 beta discussion
Post by: CFSworks on February 09, 2012, 03:43:57 AM
What I doing wrong? Ubuntu:

I'm getting what looks to be the same issue as mich, I'm on Debian 6:

Sorry about that! Apparently I don't know how to use setuptools correctly. :D

I just pushed a fix for that problem into the Github repository. You can try that if you like.

Because o has to come before p, opencl before phatk2. Maybe you should rename it 00-opencl. ;)

A better fix for that problem is to use a function which loads the kernel if it hasn't already been imported. I'm working on that now...


Title: Re: Phoenix 2 beta discussion
Post by: CFSworks on February 09, 2012, 03:49:59 AM

CFSWorks, could you please verify the crc of current windows build of phoenix.exe is 89B9736A ? I keep getting told that the windows build was updated but i'm just not seeing it because the "new" and "old" crc32s are identical, so I don't believe anything was updated/changed.

I just checked - the zipfile itself is identical. I'm going to go badger jedi95 to compile a new one.


Title: Re: Phoenix 2 beta discussion
Post by: CFSworks on February 09, 2012, 04:01:49 AM
-- snip -- (accidentally quoted the main post)


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 09, 2012, 04:47:29 AM

CFSWorks, could you please verify the crc of current windows build of phoenix.exe is 89B9736A ? I keep getting told that the windows build was updated but i'm just not seeing it because the "new" and "old" crc32s are identical, so I don't believe anything was updated/changed.

I just checked - the zipfile itself is identical. I'm going to go badger jedi95 to compile a new one.

Thanks! :)


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 09, 2012, 07:35:21 AM
Hashrate display is fixed on latest build, good job!

Another problem I observed with my own kernel (DiaKGCN), if I use a 7970 (Tahiti - GCN) seperate everything is okay, if I use a 6550D (BeaverCreek - VLIW5) everything is okay, but if I try to use both of them together there seems to be a problem.

Code:
[general]
autodetect = +cl -cpu
backend = http://XYZ:XYZ@pool.bitlc.net
ratesamples = 100
verbose = true

[cl:0:0]
disabled = false
kernel = diakgcn
aggression = 12
goffset = true
vectors2 = true
vectors4 = false
vectors8 = false
worksize = 256

[cl:0:1]
disabled = false
kernel = diakgcn
aggression = 12
goffset = true
vectors2 = false
vectors4 = false
vectors8 = true
worksize = 128

Hashrate for each device is ~540 MH/s + 60 MH/s, which should lead to ~600 MH/s for the above config. Real displayed rate is only 114 MH/s, so it seems the kernel does not use the supplied settings for each device but perhaps uses only the last supplied parameters (here for [cl:0:1]. Could well be a problem of my init / kernel, but could also be a general problem. Any ideas?

Dia


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 09, 2012, 07:48:56 AM
Hashrate display is fixed on latest build, good job!

Another problem I observed with my own kernel (DiaKGCN), if I use a 7970 (Tahiti - GCN) seperate everything is okay, if I use a 6550D (BeaverCreek - VLIW5) everything is okay, but if I try to use both of them together there seems to be a problem.

Code:
[general]
autodetect = +cl -cpu
backend = http://XYZ:XYZ@pool.bitlc.net
ratesamples = 100
verbose = true

[cl:0:0]
disabled = false
kernel = diakgcn
aggression = 12
goffset = true
vectors2 = true
vectors4 = false
vectors8 = false
worksize = 256

[cl:0:1]
disabled = false
kernel = diakgcn
aggression = 12
goffset = true
vectors2 = false
vectors4 = false
vectors8 = true
worksize = 128

Hashrate for each device is ~540 MH/s + 60 MH/s, which should lead to ~600 MH/s for the above config. Real displayed rate is only 114 MH/s, so it seems the kernel does not use the supplied settings for each device but perhaps uses only the last supplied parameters (here for [cl:0:1]. Could well be a problem of my init / kernel, but could also be a general problem. Any ideas?

Dia

I'm going to need more info to figure this one out. Multiple kernels is working fine on one of my rigs with a 5870 + 5830.

Things to check:
Can you try this using opencl and/or phatk2 kernels for both devices?
What load % are you getting on each GPU?
Is the CPU load % being maxed out? (perhaps a bug in the CPU detection code you submitted?) "autodetect = +cl -cpu" would use the CPU if the detection code doesn't work.


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 09, 2012, 08:28:41 AM
These pictures are not phatk, but DiaKGCN!

6550D:
http://gpuz.techpowerup.com/12/02/09/6y0.png

7950:
http://gpuz.techpowerup.com/12/02/09/4wh.png

I set an affinity to only one of my 4 CPU cores and utilisation jumps between 100% and 50% for that single core.
The CPU device was disabled via:
Code:
[cl:0:2]
disabled = true

Utilisation for the GPUs looks very weird...

Autoconfiguration for both GPUs lead to a higher Hashrate, but 7970 has a GPU load only at 75% max. I guess there is a problem with setting different worksizes or vector widths for different GPUs here and that autoconfig sets the same values for both devices, which is not optimal, too and only makes the problem less obvious.

Dia


Title: Re: Phoenix 2 beta discussion
Post by: d3m0n1q_733rz on February 10, 2012, 06:06:59 AM
6550D:
http://gpuz.techpowerup.com/12/02/09/6y0.png

7950:
http://gpuz.techpowerup.com/12/02/09/4wh.png

I set an affinity to only one of my 4 CPU cores and utilisation jumps between 100% and 50% for that single core.
The CPU device was disabled via:
Code:
[cl:0:2]
disabled = true

Utilisation for the GPUs looks very weird...

Autoconfiguration for both GPUs lead to a higher Hashrate, but 7970 has a GPU load only at 75% max. I guess there is a problem with setting different worksizes or vector widths for different GPUs here and that autoconfig sets the same values for both devices, which is not optimal, too and only makes the problem less obvious.

Dia
I don't think that autoconfig actually sets Vector and worksize properly anyway.  When I used it all it set was the phatk2 kernel usage and no other parameters.

Speaking of Phatk2, I think something needs to be done with the nonce determination at the end of the program.  You see, it compares the different vectors of v and g for equivalence and then sets nonce to the corresponding value of W[3]'s vector.  Unfortunately, nonce is a uint and can contain only one vector's value.  This makes the assumption that only a single vector will be okay to use.  And, should more than one vector be proper to utilize, nonce is set to the highest vector's value.  So, one of two things needs to be done:
1)  Only check vectors as long as nonce remains 0.  Any remaining checks will be wasted.
2)  Expand nonce to the size of the vectors used and allow the use of multiple nonce, if found, to increase efficiency.

In any case, the nonce determination code needs to be modified.  I suggest doing a 64-bit atom_and of v and g and then pulling the values of W[3] out based upon each vector in v having all bits equal to 1.  This still has the problem of having multiple nonce possible though.  But it will only be comparing bits in v to 1.  This also mean that we can skip the nonce check all together in the case that we have more results without nonce than with by testing if v=0.  If v=0, don't bother pulling out the nonce values, because they're not there.  If every bit in a vector of v is not 1, don't pull out the corresponding value in W[3].  It saves a heck of a lot of time.

I made a miscalculation here.  Even if we AND the vectors, some bits will still probably match which means it still needs to pull the vectors apart to check each one against the constant of all 1 bits.  Too bad we can't AND or XOR an entire vector to equal 1 or 0 that I know of.


Title: Re: Phoenix 2 beta discussion
Post by: blandead on February 11, 2012, 02:58:15 AM
I don't think that autoconfig actually sets Vector and worksize properly anyway.  When I used it all it set was the phatk2 kernel usage and no other parameters.

Speaking of Phatk2, I think something needs to be done with the nonce determination at the end of the program.  You see, it compares the different vectors of v and g for equivalence and then sets nonce to the corresponding value of W[3]'s vector.  Unfortunately, nonce is a uint and can contain only one vector's value.  This makes the assumption that only a single vector will be okay to use.  And, should more than one vector be proper to utilize, nonce is set to the highest vector's value.  So, one of two things needs to be done:
1)  Only check vectors as long as nonce remains 0.  Any remaining checks will be wasted.
2)  Expand nonce to the size of the vectors used and allow the use of multiple nonce, if found, to increase efficiency.

In any case, the nonce determination code needs to be modified.  I suggest doing a 64-bit atom_and of v and g and then pulling the values of W[3] out based upon each vector in v having all bits equal to 1.  This still has the problem of having multiple nonce possible though.  But it will only be comparing bits in v to 1.  This also mean that we can skip the nonce check all together in the case that we have more results without nonce than with by testing if v=0.  If v=0, don't bother pulling out the nonce values, because they're not there.  If every bit in a vector of v is not 1, don't pull out the corresponding value in W[3].  It saves a heck of a lot of time.

I made a miscalculation here.  Even if we AND the vectors, some bits will still probably match which means it still needs to pull the vectors apart to check each one against the constant of all 1 bits.  Too bad we can't AND or XOR an entire vector to equal 1 or 0 that I know of.

You can AND or XOR whatever you want if it's set up to do so
T atom_and (Q T*p, T val) | Read, Store (*p & val)
T atom_xor (Q T*p, T val) | Read, Store(*p ^ val)

The reason you can't expand the nonce is because the base is a uint (as you pointed out), only with floats or double can you do that

If you have float4 v; corresponding values are (v.x, v.s0), (v.y, v.s1), (v.z, v.s2), (v.w, v.s3)

Then just next them together into v.xyzw or v.s0123
or v.lo (v.s01, v.xy) or v.hi (v.s23, v.zw) or v.odd(v.s13, v.yw) or v.even(v.s02, v.xz)
or whatever combination you want

There is a way to directly test sign bits btw,
intn signbit(floatn)

There is also a separate function to test if all bits are 1 compared to a constant

You can test for finite values, +infinity or -infinity, NaN, do a bitselect or a select function for vector types

Unfortunately the _init_.py does not have any of it set up properly, the way the buffer is created, stored, and read is a very slow method compared to what is possible now

Also, there is a way to create an offset function natively as well plus many more options


Title: Re: Phoenix 2 beta discussion
Post by: d3m0n1q_733rz on February 11, 2012, 09:40:15 AM
I don't think that autoconfig actually sets Vector and worksize properly anyway.  When I used it all it set was the phatk2 kernel usage and no other parameters.

Speaking of Phatk2, I think something needs to be done with the nonce determination at the end of the program.  You see, it compares the different vectors of v and g for equivalence and then sets nonce to the corresponding value of W[3]'s vector.  Unfortunately, nonce is a uint and can contain only one vector's value.  This makes the assumption that only a single vector will be okay to use.  And, should more than one vector be proper to utilize, nonce is set to the highest vector's value.  So, one of two things needs to be done:
1)  Only check vectors as long as nonce remains 0.  Any remaining checks will be wasted.
2)  Expand nonce to the size of the vectors used and allow the use of multiple nonce, if found, to increase efficiency.

In any case, the nonce determination code needs to be modified.  I suggest doing a 64-bit atom_and of v and g and then pulling the values of W[3] out based upon each vector in v having all bits equal to 1.  This still has the problem of having multiple nonce possible though.  But it will only be comparing bits in v to 1.  This also mean that we can skip the nonce check all together in the case that we have more results without nonce than with by testing if v=0.  If v=0, don't bother pulling out the nonce values, because they're not there.  If every bit in a vector of v is not 1, don't pull out the corresponding value in W[3].  It saves a heck of a lot of time.

I made a miscalculation here.  Even if we AND the vectors, some bits will still probably match which means it still needs to pull the vectors apart to check each one against the constant of all 1 bits.  Too bad we can't AND or XOR an entire vector to equal 1 or 0 that I know of.

You can AND or XOR whatever you want if it's set up to do so
T atom_and (Q T*p, T val) | Read, Store (*p & val)
T atom_xor (Q T*p, T val) | Read, Store(*p ^ val)

The reason you can't expand the nonce is because the base is a uint (as you pointed out), only with floats or double can you do that

If you have float4 v; corresponding values are (v.x, v.s0), (v.y, v.s1), (v.z, v.s2), (v.w, v.s3)

Then just next them together into v.xyzw or v.s0123
or v.lo (v.s01, v.xy) or v.hi (v.s23, v.zw) or v.odd(v.s13, v.yw) or v.even(v.s02, v.xz)
or whatever combination you want

There is a way to directly test sign bits btw,
intn signbit(floatn)

There is also a separate function to test if all bits are 1 compared to a constant

You can test for finite values, +infinity or -infinity, NaN, do a bitselect or a select function for vector types

Unfortunately the _init_.py does not have any of it set up properly, the way the buffer is created, stored, and read is a very slow method compared to what is possible now

Also, there is a way to create an offset function natively as well plus many more options

Supposing we did fit two found nonce values into a single nonce, could the miner output them both from a uint2?  And the v.s0 is the same as v.x for uint2 or uint4 as well.  When you get into uint8 or above, they become explicitly v.s0 etc.  They're really just vector locations.
But would the miner know to cut the nonce apart or would it expect a single uint?


Title: Re: Phoenix 2 beta discussion
Post by: iNs4nePT on February 11, 2012, 03:28:00 PM
Edited: my bad, don't forget "agression" != "aggression" :)

Hash rate still seems a bit lower than phoenix 1.7.5 on an OC'd 6850


Is there any possibility to select the pool from command line?
Either passing the full url, or a configuration key name would be great.


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 11, 2012, 07:42:35 PM
Edited: my bad, don't forget "agression" != "aggression" :)

Hash rate still seems a bit lower than phoenix 1.7.5 on an OC'd 6850


Is there any possibility to select the pool from command line?
Either passing the full url, or a configuration key name would be great.


There are a few ways to do this.

First, the only argument Phoenix 2 accepts on the command line is the path to its config file. If none is supplied, it defaults to phoenix.cfg in the current working directory. Using this method you could have several config files (one per pool) and simply switch between them.

The second method is to use Phoenix 2's RPC interface to switch pools at runtime. The following code is an example of how to do this in Python:
Code:
import jsonrpc
sp = jsonrpc.ServiceProxy('http://x:phoenix@localhost:7780')
sp.setconfig('general', 'backend', 'http://user:password@pool.com:8332')

This will cause Phoenix to switch to the new pool immediately.


Title: Re: Phoenix 2 beta discussion
Post by: blandead on February 12, 2012, 08:47:14 PM
Supposing we did fit two found nonce values into a single nonce, could the miner output them both from a uint2?  And the v.s0 is the same as v.x for uint2 or uint4 as well.  When you get into uint8 or above, they become explicitly v.s0 etc.  They're really just vector locations.
But would the miner know to cut the nonce apart or would it expect a single uint?

Yes there is a way to output directly 4 values

and again it can't be a uint, it has to be a float

with float4 v.s0 and v.x are not the same, I don't think at least since, it's still a 4 component variable (float4)


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 12, 2012, 09:00:41 PM
Supposing we did fit two found nonce values into a single nonce, could the miner output them both from a uint2?  And the v.s0 is the same as v.x for uint2 or uint4 as well.  When you get into uint8 or above, they become explicitly v.s0 etc.  They're really just vector locations.
But would the miner know to cut the nonce apart or would it expect a single uint?

Yes there is a way to output directly 4 values

and again it can't be a uint, it has to be a float

with float4 v.s0 and v.x are not the same, I don't think at least since, it's still a 4 component variable (float4)

Why should .s0 and .x be not the same? For 4-component vectors it's possible to use .x .y .z .w or s0 s1 s2 s3 as per OpenCL spec.
To oputput 2 nonce values in one variable we can use ulong, that's what's currently used in DiaKGCN or my last phatk_dia (I did change that though in my last internal version). To output 4 values this could be done via vstore() I guess.

Dia


Title: Re: Phoenix 2 beta discussion
Post by: blandead on February 13, 2012, 08:00:47 AM
Why should .s0 and .x be not the same? For 4-component vectors it's possible to use .x .y .z .w or s0 s1 s2 s3 as per OpenCL spec.
To oputput 2 nonce values in one variable we can use ulong, that's what's currently used in DiaKGCN or my last phatk_dia (I did change that though in my last internal version). To output 4 values this could be done via vstore() I guess.

Dia

My mistake it is the same, just be careful when using .lo or .hi functions as if you have a float2 .lo can mean .x or .s0, of course you can always use .lo.x if you want to be extra specific.

Sure you can use ulong, and it takes an extra 10+ instructions to output the nonces while you upsample it, instead of outputting all nonces at once with just one output function.

A vstore() writes the vector data to memory, and a vload() reads it from memory. Probably with Async copies and Prefetch it can be done


Title: Re: Phoenix 2 beta discussion
Post by: d3m0n1q_733rz on February 13, 2012, 10:26:10 AM
Supposing we did fit two found nonce values into a single nonce, could the miner output them both from a uint2?  And the v.s0 is the same as v.x for uint2 or uint4 as well.  When you get into uint8 or above, they become explicitly v.s0 etc.  They're really just vector locations.
But would the miner know to cut the nonce apart or would it expect a single uint?

Yes there is a way to output directly 4 values

and again it can't be a uint, it has to be a float

with float4 v.s0 and v.x are not the same, I don't think at least since, it's still a 4 component variable (float4)

Why should .s0 and .x be not the same? For 4-component vectors it's possible to use .x .y .z .w or s0 s1 s2 s3 as per OpenCL spec.
To oputput 2 nonce values in one variable we can use ulong, that's what's currently used in DiaKGCN or my last phatk_dia (I did change that though in my last internal version). To output 4 values this could be done via vstore() I guess.

Dia
Dia, didn't you use a conditional statement that directly output the nonce to the miner instead of storing them and then outputting them at the end?
Why should .s0 and .x be not the same? For 4-component vectors it's possible to use .x .y .z .w or s0 s1 s2 s3 as per OpenCL spec.
To oputput 2 nonce values in one variable we can use ulong, that's what's currently used in DiaKGCN or my last phatk_dia (I did change that though in my last internal version). To output 4 values this could be done via vstore() I guess.

Dia

My mistake it is the same, just be careful when using .lo or .hi functions as if you have a float2 .lo can mean .x or .s0, of course you can always use .lo.x if you want to be extra specific.

Sure you can use ulong, and it takes an extra 10+ instructions to output the nonces while you upsample it, instead of outputting all nonces at once with just one output function.

A vstore() writes the vector data to memory, and a vload() reads it from memory. Probably with Async copies and Prefetch it can be done
In 2 vectors, .x is the same as .s0, .even and .lo.  However, the only reason to use the last two is if you have code designed to handle multiple different vector types and you need to output the even or lower half of the results and don't want to rewrite the entire code for each vector type.
I tend to just bother with the .s# version as it's easier and the other appears to be becoming legacy (matter of opinion of course).  Just remember that the vector after .s9 is .sa as it's numbered in hexidecimal.


Title: Re: Phoenix 2 beta discussion
Post by: blandead on February 13, 2012, 12:58:21 PM
This is a good point, might as well just use .s0 - .sf


Title: Re: Phoenix 2 beta discussion
Post by: m3ta on February 14, 2012, 04:21:46 AM
Code:
[04:20:30] [Cypress 0] Error: Device returned hash with difficulty < 1

Unusable for P2Pool, then?


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 14, 2012, 05:07:33 AM
Code:
[04:20:30] [Cypress 0] Error: Device returned hash with difficulty < 1

Unusable for P2Pool, then?

Do you only get that for p2pool? I only get that error when the hardware itself is freaking out due to bad clocks.

edit: iirc, p2pool uses >1 difficulty shares, not <1.


Title: Re: Phoenix 2 beta discussion
Post by: rjk on February 14, 2012, 05:08:44 AM
Code:
[04:20:30] [Cypress 0] Error: Device returned hash with difficulty < 1

Unusable for P2Pool, then?
P2Pool shares are >1 not <1 ;)


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 14, 2012, 02:51:33 PM
Phoenix 2 has a very big problem left, that Phoenix 1.X had, too and that is with an AGGRESSION > 12 the miner doesn't get work fast enough and switches to idle. Is there any possible fix or idea for this? I could achieve higher Hash-rates, if I could use AGGRESSION=13 or even 14, perhaps more ...

Any work-in-progress updates for us, Github is untouched for a few days now :-(.

Dia


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 14, 2012, 05:24:35 PM
Phoenix 2 has a very big problem left, that Phoenix 1.X had, too and that is with an AGGRESSION > 12 the miner doesn't get work fast enough and switches to idle. Is there any possible fix or idea for this? I could achieve higher Hash-rates, if I could use AGGRESSION=13 or even 14, perhaps more ...

Any work-in-progress updates for us, Github is untouched for a few days now :-(.

Dia

Simple fix: set queuesize = 2 under the [general] config section.

If that doesn't work please post the last 10 or so log entries. Make sure you have verbose = True before doing this.


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 14, 2012, 05:29:10 PM
I tried even a size of 4 for the queue, but does not seem to change things ... will make a short test with the default kernel.

Code:
[02/14/2012 18:25:39] Welcome to Phoenix v2.0.0-rc1
[18:25:39] [cl:0:0] using PyOpenCL version 0.92
[18:25:39] [cl:0:0] checked nonces per kernel execution: 1073741824
[18:25:39] [cl:0:0] using VECTORS2, resulting global worksize is: 536870912
[18:25:39] [cl:0:0] using local worksize of 256 (HW max. is 256)
[18:25:39] [cl:0:0] BFI_INT patching not supported on Tahiti
[18:25:39] [cl:0:0] OpenCL >= 1.1 supported, using global offset
[18:25:39] [cl:0:0] compiling new binary 964a92db0bd7570eb1762e7f91d020a7.elf

[18:25:41] Connected to server
[18:25:41] Server gave new work; passing to WorkQueue
[18:25:41] New block (WorkQueue)
[18:25:41] Currently on block: 166796
[18:25:47] Server gave new work; passing to WorkQueue
[18:25:47] [cl:0:0] positive nonce (3): 1260639519
[18:25:53] [cl:0:0] positive nonce (1): 109979338
[18:25:53] Server gave new work; passing to WorkQueue
[18:25:53] [cl:0:0] positive nonce (3): 1811269341
[18:25:59] [cl:0:0] Result 00000000b0f790d5... ACCEPTED
[18:26:05] [cl:0:0] Result 0000000036a87fc4... ACCEPTED
[18:26:05] Warning: work queue empty, miner is idle
[18:26:05] Server gave new work; passing to WorkQueue
[18:26:11] [cl:0:0] Result 0000000003beb3fb... ACCEPTED
[18:26:11] Warning: work queue empty, miner is idle
[18:26:13] Server gave new work; passing to WorkQueue
[18:26:19] Server gave new work; passing to WorkQueue
[18:26:19] [cl:0:0] positive nonce (3): 2196460551
[18:26:25] Server gave new work; passing to WorkQueue
[18:26:25] [cl:0:0] positive nonce (1): 1814499190
[18:26:27] [cl:0:0] positive nonce (3): 2017430311
[18:26:27] [cl:0:0] Result 00000000027dc443... ACCEPTED
[18:26:32] [cl:0:0] positive nonce (3): 420831727
[18:26:32] Server gave new work; passing to WorkQueue
[18:26:38] [cl:0:0] Result 0000000038b01fb1... ACCEPTED
[18:26:44] [cl:0:0] Result 0000000023ea8f21... ACCEPTED
[18:26:44] Warning: work queue empty, miner is idle
[18:26:44] [cl:0:0] positive nonce (3): 3541919045
[18:26:44] [cl:0:0] Result 00000000562b0839... ACCEPTED
[18:26:44] Server gave new work; passing to WorkQueue
[18:26:50] [cl:0:0] Result 0000000047f59358... ACCEPTED
[18:26:50] Warning: work queue empty, miner is idle
[18:26:52] Server gave new work; passing to WorkQueue

That is with following config:

Code:
[general]
autodetect = +cl -cpu
backend = http://XXX:YYY@pool.bitlc.net
queuesize = 2
ratesamples = 100
verbose = true

[cl:0:0]
disabled = false
kernel = diakgcn
aggression = 14
goffset = true
vectors2 = true
vectors4 = false
vectors8 = false
worksize = 256

[cl:0:1]
disabled = true
kernel = diakgcn
aggression = 12
goffset = true
vectors2 = false
vectors4 = false
vectors8 = true
worksize = 128

[cl:0:2]
disabled = true

[web]
disabled = true

Update with "opencl" as kernel, the problem seems gone ... weird. Seems like a glitch with my kernel, sorry jedi95 ...

Dia


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 14, 2012, 05:39:08 PM
Interesting, seems like the fix was simply to remove the ", is_blocking=True" parameter I had in my init on both cl.enqueue_ commands and re-enable the use of self.commandQueue.finish().

Edit: Another strange observation is, that Phoenix seems faster (is quicker at the highest rate) without verbose = true ... does that make any sense???

Dia


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 15, 2012, 04:44:26 AM
Interesting, seems like the fix was simply to remove the ", is_blocking=True" parameter I had in my init on both cl.enqueue_ commands and re-enable the use of self.commandQueue.finish().

Edit: Another strange observation is, that Phoenix seems faster (is quicker at the highest rate) without verbose = true ... does that make any sense???

Dia

Glad you got that figured out.

I also traced the root of the PyOpenCL issues with 2011.1 and 2011.2. The PyOpenCL commit that introduced the problem is 13d825712c57598085445b748084f9257b14981f "Default is_blocking to True."

The fix is to simply set is_blocking=False. At first glance it is very confusing as to why this would cause getting work to take much longer. Getting work is performed in the main thread and the kernel uses a separate thread for mining. The root problem is Python's GIL. (Global Interpreter Lock, see here (http://wiki.python.org/moin/GlobalInterpreterLock) for details) Your performance issue with is_blocking=True was most likely also due to the GIL.

Anyway, as a result of this being resolved future Windows builds of Phoenix will use the latest PyOpenCL.


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 15, 2012, 05:46:30 AM
Interesting, seems like the fix was simply to remove the ", is_blocking=True" parameter I had in my init on both cl.enqueue_ commands and re-enable the use of self.commandQueue.finish().

Edit: Another strange observation is, that Phoenix seems faster (is quicker at the highest rate) without verbose = true ... does that make any sense???

Dia

Glad you got that figured out.

I also traced the root of the PyOpenCL issues with 2011.1 and 2011.2. The PyOpenCL commit that introduced the problem is 13d825712c57598085445b748084f9257b14981f "Default is_blocking to True."

The fix is to simply set is_blocking=False. At first glance it is very confusing as to why this would cause getting work to take much longer. Getting work is performed in the main thread and the kernel uses a separate thread for mining. The root problem is Python's GIL. (Global Interpreter Lock, see here (http://wiki.python.org/moin/GlobalInterpreterLock) for details) Your performance issue with is_blocking=True was most likely also due to the GIL.

Anyway, as a result of this being resolved future Windows builds of Phoenix will use the latest PyOpenCL.

Very nice, now that are pretty good news :) ... when can we test the next release?
Thanks for your hard work on that long standing issue jedi!

Dia


Title: Re: Phoenix 2 beta discussion
Post by: CFSworks on February 15, 2012, 07:12:59 AM

Very nice, now that are pretty good news :) ... when can we test the next release?
Thanks for your hard work on that long standing issue jedi!

Dia

Sorry for leaving the Git repository untouched - I wore myself out on RC1 and needed a break. Getting back to work now!

No promises, but we might be able to get rc2 released in about 24 hours. Changes to be in rc2:
  • Better kernel import mechanism (fix bug with phatk2 depending on opencl).
  • Some semblance of a PluginInterface.
  • jedi95 is making some kernel-level improvements
  • Misc. bugfixes (got the Python-on-Linux installer working right, etc)
  • Support for submitold (addresses some concerns (https://github.com/jedi95/Phoenix-Miner/pull/3) forrestv had)
  • Maybe backup pool support, if it's easy to tackle after this... otherwise we'll add it post-release

And of course, it is a release candidate. If all goes well, rc2 will be the official release version. ;D


Title: Re: Phoenix 2 beta discussion
Post by: Schwede65 on February 15, 2012, 08:29:24 AM

Very nice, now that are pretty good news :) ... when can we test the next release?
Thanks for your hard work on that long standing issue jedi!

Dia

Sorry for leaving the Git repository untouched - I wore myself out on RC1 and needed a break. Getting back to work now!

No promises, but we might be able to get rc2 released in about 24 hours. Changes to be in rc2:
  • Better kernel import mechanism (fix bug with phatk2 depending on opencl).
  • Some semblance of a PluginInterface.
  • jedi95 is making some kernel-level improvements
  • Misc. bugfixes (got the Python-on-Linux installer working right, etc)
  • Support for submitold (addresses some concerns (https://github.com/jedi95/Phoenix-Miner/pull/3) forrestv had)
  • Maybe backup pool support, if it's easy to tackle after this... otherwise we'll add it post-release

And of course, it is a release candidate. If all goes well, rc2 will be the official release version. ;D

rc1 is running stable and with low stales, the only missing point for me is the backup-pool support...

i do it now with parallel-mining 1.75, but the stales are significant higher: 2-3 x higher...

keep up your great work...


Title: Re: Phoenix 2 beta discussion
Post by: CFSworks on February 15, 2012, 08:50:09 AM
I just posted a bounty for a web developer to write a nice web control panel. If you want to see it happen as much as we do, see the main post for the link to the bounty thread. :)


Title: Re: Phoenix 2 beta discussion
Post by: macbook-air on February 18, 2012, 10:43:35 PM
Code:
[04:20:30] [Cypress 0] Error: Device returned hash with difficulty < 1

Unusable for P2Pool, then?
P2Pool shares are >1 not <1 ;)

No. The initial difficulty is slightly < 1, at 0.999985.


Title: Re: Phoenix 2 beta discussion
Post by: CFSworks on February 18, 2012, 11:33:25 PM
Code:
[04:20:30] [Cypress 0] Error: Device returned hash with difficulty < 1

Unusable for P2Pool, then?

That error means the card found a hash where state_H != 0. While the error should really be "difficulty < 0.9999847..." we just round up to 1.

Because the OpenCL code only returns nonces satisfying state_H == 0, this is most certainly a hardware/OpenCL/kernel problem and not an unusual interaction with P2Pool.


Title: Re: Phoenix 2 beta discussion
Post by: mc_lovin on February 19, 2012, 08:09:00 PM
I absolutely love Phoenix 2. 

I installed it on a dozen systems, and everything went smooth, hashing all around.

But then I figured I could squeeze a few extra hashes out of my main system here, i was getting 1.12GH/s with a 5970 & a 5870, Windows 7 x64.

All my other systems are just running the latest ATI drivers, but everyone is raving about 11.6 and SDK 2.1, so I figured I would give it a shot and roll back my drivers. 

I installed 11.6 and SDK 2.1, and now I'm having issues.  I would uninstall ALL ATI software, install 11.6 then 2.1, uninstall, try 2.1 then 11.6, over and over, trying to figure out the order in which to install them.  I know the order shouldn't matter, but installing SDK 2.1 seemed to have an affect.  Installing the drivers as I thought they should be installed would work until I tried mining with Phoenix.  MSI Afterburner would report the proper Catalyst version, and it would mine when I started it except I would get bluescreens, total lockups, or it wouldn't detect OpenCL.  Also, it would appear that when I install 11.6, everything is good, but installing 2.1 gives me an additional unwanted GPU in Phoenix.

Screenshot 1 (http://bitcointrading.com/img/phoenixhelp1.jpg)

Right now in my cfg file, if I leave all my configuration commented (just the card configuration) it should default and start mining.  It shows 4 GPUs.  This only appears after I install SDK 2.1.  Hopefully I have the right version, the app filename is ati-stream-sdk-v2.1-vista-win7-64.exe.  .  This current installation I have uninstalled ALL ATI software, installed 12.1 drivers and SDK 2.1.  If I just install 12.1, it only hashes at 1.00GHz (120MH/s less than before) but when I install 2.1 it gives me much faster speeds but not faster than before I started messing with things.  Once I install 2.1, my CPU USAGE IS ZERO on all cores.  This is why I haven't changed the current installation.  In this first screenshot, it detects [cl:0:0], [cl:1:1], [cl:1:2], and [cl:1:3], however when it starts mining, I see [cl:0:1] and [cl:0:2] submitting shares (these, plus [cl:0:3], are what it should be displaying, or at least it did before), additionally we see [Cypress 0,1,2] submitting shares, so there's some madness going on! 

Screenshot 2 (http://bitcointrading.com/img/phoenixhelp2.jpg)

So if it detected [cl:0:0], so let's tell it to ignore it.  [cl:0:0] disabled = true was added to the above screenshot.  You can see it no longer detects it, but we still have shares coming from both the [cl:0:1]/[cl:0:2]/[Cypress 0,1,2].

Screenshot 3 (http://bitcointrading.com/img/phoenixhelp3.jpg)

So I figured if it is detecting [cl:1:1], [cl:1:2], and [cl:1:3], let's disable them.  I commented the [cl:0:0] disabled line because if it isn't commented it doesn't use the 5870 at all.

Screenshot 4 (http://bitcointrading.com/img/phoenixhelp4.jpg)

So let's uncomment the card configurations.  CPU usage goes up.  It actually feels like it's mining now.  Hashrate is around 1.04 GH/s.  If I leave the [cl:1:1], 2, 3 disabled = true lines off then it detects them and then I see the [Cypress 0,1,2] submitting shares as well. 

Screenshot 5 (http://bitcointrading.com/img/phoenixhelp5.jpg)

This is an interesting situation.  Hashrates go up to 1.16GH/s and CPU usage is ZERO.  The system has very low stale shares except I let it run all night and it crashed some point in the night.  Also, temps are higher here than ever.

I think i'll stop with the screenshot posting madness, I'm just trying to figure out why sometimes my CPU usage can be zero and hashrates be high, when sometimes I install 11.6 and my CPU usage is 100% on all cores.  Bearing in mind, all my other computers are mining happily and this is the only machine I am having problems with.  If I uninstall all ATI software on it and put on 12.1, my hashrates do not go above 1.00 GH/s.  Sum Ting Wong!

Are these bugs in Phoenix?  Something I am doing wrong when installing drivers?  Is there a magical order to the installation?  When installing your ATI drivers, do you uncheck the SDK version from the custom installation and then install SDK 2.1 after?   Or before?  I tried unchecking the SDK version in installation and Phoenix said it didn't see any OpenCL devices.  If I put 11.6 on here I get bluescreens and driver crashes constantly so I might need some advice.  My goal here would be to have 0% CPU usage and go back to a 'normal' situation where devices are detected properly.


Title: Re: Phoenix 2 beta discussion
Post by: mc_lovin on February 19, 2012, 11:12:37 PM
Today's new GUI miner release has somewhat solved my problem. 

I see that when I install 11.6, there are 3 devices, [cl:0:0], [cl:0:1], and [cl:0:2].

After installing SDK 2.1, there are now many more devices.
[cl:0:0] - Intel CPU
[cl:0:1] - Cypress
[cl:0:2] - Cypress
[cl:0:3] - Cypress
[cl:1:0] - Cypress
[cl:1:1] - Cypress
[cl:1:2] - Cypress
[cl:1:3] - Intel CPU

Which brings me to the conclusion that SDK installs an entire additional OpenCL platform for all devices.  Makes perfect sense.  Using the 0 platform devices, I get pretty decent hashrates (1.11 GH/s) and using the 1 platform devices I get pretty shoddy hashrates. 

My CPU usage is once again 100% on one thread, but I can live with that unless someone can shed some light on how to avoid this, but at least i'm hashing!


Title: Re: Phoenix 2 beta discussion
Post by: niooron on February 20, 2012, 02:50:42 AM
I'm trying to mine using stream 2.1 sdk using the latest catalyst 12.2, and it doesnt work, the miner never sends any shares, even though it shows the expected mhash/sec. Phoenix 1.7.5 works fine using stream 2.1 with the platform=1 switch.

My config:

[cl:0:0]
disabled = true
[cl:0:1]
disabled = true
[cl:0:2]
disabled = true
[cl:1:0]
disabled = true
[cl:1:1]
autoconfigure = true
aggression = 12
[cl:1:2]
autoconfigure = true
aggression = 12


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 20, 2012, 11:16:05 AM
You dont need to say disabled for any device, unless you have autodetect up top. autodetect is really just a miner noob way of getting phoenix to work. All devices are "disabled" without autodetect unless you specify the devices later in the config file.


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 20, 2012, 11:17:11 AM
Today's new GUI miner release has somewhat solved my problem.  

I see that when I install 11.6, there are 3 devices, [cl:0:0], [cl:0:1], and [cl:0:2].

After installing SDK 2.1, there are now many more devices.
[cl:0:0] - Intel CPU
[cl:0:1] - Cypress
[cl:0:2] - Cypress
[cl:0:3] - Cypress
[cl:1:0] - Cypress
[cl:1:1] - Cypress
[cl:1:2] - Cypress
[cl:1:3] - Intel CPU

Which brings me to the conclusion that SDK installs an entire additional OpenCL platform for all devices.  Makes perfect sense.  Using the 0 platform devices, I get pretty decent hashrates (1.11 GH/s) and using the 1 platform devices I get pretty shoddy hashrates.  

My CPU usage is once again 100% on one thread, but I can live with that unless someone can shed some light on how to avoid this, but at least i'm hashing!

use 11.12 driver to avoid cpu bug on 2.1 sdk with multi-gpu. and yes, 2.1 install path and platform is entirely different from amd app (2.4+). you can have 2.1 and any one sdk from 2.4-2.6 installed on the same system. my config looks like this on my gamer system.
Code:
[general]
verbose = True
backend = http://1CxcPP8FVktppy4PHTYJKnZFqQeyZ3jArb:x@mining.eligius.st:8337

[cl:0:1]
kernel = phatk2
AGGRESSION = 4
VECTORS4 = true
BFI_INT = true
WORKSIZE = 64

[cl:1:1]
kernel = phatk2
AGGRESSION = 14
VECTORS = true
BFI_INT = true
WORKSIZE = 256

[web]
disable = true

the first device is gpu i game on, and since memory speed is stock or a little higher, its best to use sdk 2.6 with it and vectors4 + w64. the second device is a dedicated gpu using 2.1 sdk. TdrDelay in registry was changed to be 15 seconds instead of default of 2 in order to prevent driver reset due to the high aggression.


Title: Re: Phoenix 2 beta discussion
Post by: CFSworks on February 22, 2012, 10:19:30 AM
Phoenix 2.0.0-rc2 is now up.

We changed lots of things here and there, but that should have taken care of all of the known bugs. As always, please test it and let us know. :)

The changes include:
  • The kernels directory has been renamed to plugins
  • Kernel API has been slightly modified
  • An advanced-level example config is included in the doc directory (courtesy of jedi95)
  • Backup pools are now possible (see first post for example)
  • A handful of bug fixes

Still to be implemented for release:
  • Web control panel? I hope (https://bitcointalk.org/index.php?topic=63970.0)?
  • PluginInterface so third-party non-kernel plugins (GPU management, GUI support, etc) can be easily created


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 22, 2012, 10:31:58 AM
There has been a significant change to the Windows build in RC2. PyOpenCL has been updated from 0.92 to 2011.2. The included kernels have been modified to work correctly under both 2011.2 and 0.92. Kernel developers should target PyOpenCL 2011.2 now.

In short:
Any kernels running under 2011.2 need to use is_blocking = False in order to prevent large delays getting work.
PyOpenCL 2011.2 has a built-in kernel binary caching system that is enabled by default. The included kernels disable this and continue to use their own system.


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 22, 2012, 11:11:15 AM
Sounds pretty cool, thanks for the changes ... if only the Windows build would be available :D.
I want to make DiakGCN RC2 compatible ^^.

Dia


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 22, 2012, 11:21:35 AM
Sounds pretty cool, thanks for the changes ... if only the Windows build would be available :D.
I want to make DiakGCN RC2 compatible ^^.

Dia

See second post:
https://bitcointalk.org/index.php?topic=62765.msg733433#msg733433

Or download it directly:
https://github.com/downloads/phoenix2/phoenix/phoenix-2.0.0-rc2.zip


Title: Re: Phoenix 2 beta discussion
Post by: CFSworks on February 22, 2012, 11:25:43 AM
Sounds pretty cool, thanks for the changes ... if only the Windows build would be available :D.
I want to make DiakGCN RC2 compatible ^^.

Dia

We had it uploaded with an extra dot in the filename... Oops! jedi95 fixed it.

The changes for RC2 should really just be renaming MiningKernel to PhoenixKernel, and putting the kernel package in "plugins" instead of "kernels" (which is no longer used as the directory name)

Edit: Let me clarify: Those changes are what are needed to get it working. You should also add jedi95's changes, since those fix some performance problems.


Title: Re: Phoenix 2 beta discussion
Post by: Diapolo on February 22, 2012, 12:52:21 PM
I can confirm backups-support works, would be nice though, if in verbose mode the url would be displayed if pool get's switched so you know to which pool you are connected. The switch to the latest pyOpenCL is a good move and this works with my kernel, too.

Dia


Title: Re: Phoenix 2 beta discussion
Post by: Schwede65 on February 23, 2012, 07:52:48 AM
W7-64-bit
rc-1 is running more stable then rc-2

running both versions on different rigs

1. when the rc-2 gave-up (server-disconnection + many rejects), backup-pool was not working
(i had my guiminer parallel working ;) )

2. when the rc-2 gave-up (server-disconnection + many rejects), rc-1 started new and stable up to now



Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 25, 2012, 01:52:14 PM
Hmm, RC1 works flawlessly. I tried RC2 but it's bugged bad? I thought it might have been incompatible with sdk 2.1 (wont hash at all), so I tried 2.6. It has a different error, but it hashes slow compared to 2.6, and I refuse to use 2.6 and be forced to use high memory clocks and waste power.

heres my config file.
Code:
[general]
verbose = True
backend = http://1CxcPP8FVktppy4PHTYJKnZFqQeyZ3jArb:x@mining.eligius.st:8337

[cl:1:1]
kernel = phatk2
AGGRESSION = 14
VECTORS = true
BFI_INT = true
WORKSIZE = 256

[web]
disable = true

heres the error with 2.1 sdk (cl:1:1)
http://dl.dropbox.com/u/9768004/error2.png

heres the error with 2.6 sdk (cl:0:0)
http://dl.dropbox.com/u/9768004/error3.png

back to using rc1 until bug is fixed.


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 25, 2012, 08:10:24 PM
Hmm, RC1 works flawlessly. I tried RC2 but it's bugged bad? I thought it might have been incompatible with sdk 2.1 (wont hash at all), so I tried 2.6. It has a different error, but it hashes slow compared to 2.6, and I refuse to use 2.6 and be forced to use high memory clocks and waste power.

back to using rc1 until bug is fixed.

A fix for this bug has been pushed to the Git repo.

https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py


Title: Re: Phoenix 2 beta discussion
Post by: blandead on February 25, 2012, 09:02:34 PM
Hmm, RC1 works flawlessly. I tried RC2 but it's bugged bad? I thought it might have been incompatible with sdk 2.1 (wont hash at all), so I tried 2.6. It has a different error, but it hashes slow compared to 2.6, and I refuse to use 2.6 and be forced to use high memory clocks and waste power.

back to using rc1 until bug is fixed.

A fix for this bug has been pushed to the Git repo.

https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py

why was self.f[8] taken out? It's working better for me with the old one


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on February 26, 2012, 03:55:34 AM
Hmm, RC1 works flawlessly. I tried RC2 but it's bugged bad? I thought it might have been incompatible with sdk 2.1 (wont hash at all), so I tried 2.6. It has a different error, but it hashes slow compared to 2.6, and I refuse to use 2.6 and be forced to use high memory clocks and waste power.

back to using rc1 until bug is fixed.

A fix for this bug has been pushed to the Git repo.

https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py

wow, thanks for fast fix, thanks. eagerly awaiting next windows build.


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on February 26, 2012, 03:58:06 AM
Hmm, RC1 works flawlessly. I tried RC2 but it's bugged bad? I thought it might have been incompatible with sdk 2.1 (wont hash at all), so I tried 2.6. It has a different error, but it hashes slow compared to 2.6, and I refuse to use 2.6 and be forced to use high memory clocks and waste power.

back to using rc1 until bug is fixed.

A fix for this bug has been pushed to the Git repo.

https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py

why was self.f[8] taken out? It's working better for me with the old one

You are confusing the phatk2 __init__.py with the opencl one. The only change is here:
https://github.com/phoenix2/phoenix/commit/9083008563fc6cffae99627e32ef8c39abf34859


Title: Re: Phoenix 2 beta discussion
Post by: blandead on February 26, 2012, 09:36:11 AM
oh sorry.. so i was going through some of the newer python methods

platform="None" is depracated now, maybe should just get rid of checking for platform and just check for device. I think platform has a function that looks it up anyways.

Also the "is_blocking" is defaulted to true, so wouldn't it be better to set it to false on the enqueue_write_buffer as well?


Title: Re: Phoenix 2 beta discussion
Post by: lodcrappo on March 01, 2012, 04:05:52 AM
So finally got around to rolling phoenix2 into BAMT.  It seems to work great, nice job.

I thought originally we'd have to write a plugin, but actually the RPC interface does everything needed except a couple statistics, and I think those are simple to add.

Right now it reports 'results' per GPU but not accepted vs rejected, and not shares that are discarded as stale or if the "Result didn't meet full difficulty, not sending" condition in KernelInterface happens.

I added simple counters for these and then included them in the results of listdevices, just like 'results' is done.  Seems to work fine though I am not sure it's the best way.  Could these types of status be added to the official rpc interface?


Title: Re: Phoenix 2 beta discussion
Post by: blandead on March 01, 2012, 06:04:14 PM
What about using atomic counters for the statistics part?


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on March 02, 2012, 12:44:30 AM
So finally got around to rolling phoenix2 into BAMT.  It seems to work great, nice job.

I thought originally we'd have to write a plugin, but actually the RPC interface does everything needed except a couple statistics, and I think those are simple to add.

Right now it reports 'results' per GPU but not accepted vs rejected, and not shares that are discarded as stale or if the "Result didn't meet full difficulty, not sending" condition in KernelInterface happens.

I added simple counters for these and then included them in the results of listdevices, just like 'results' is done.  Seems to work fine though I am not sure it's the best way.  Could these types of status be added to the official rpc interface?


I have added accepted and rejected fields to the listdevices RPC interface.

The number of shares that were not sent to the server for any reason can be found by:

shares not sent = results - (accepted + rejected)


Title: Re: Phoenix 2 beta discussion
Post by: lodcrappo on March 02, 2012, 05:01:42 PM
So finally got around to rolling phoenix2 into BAMT.  It seems to work great, nice job.

I thought originally we'd have to write a plugin, but actually the RPC interface does everything needed except a couple statistics, and I think those are simple to add.

Right now it reports 'results' per GPU but not accepted vs rejected, and not shares that are discarded as stale or if the "Result didn't meet full difficulty, not sending" condition in KernelInterface happens.

I added simple counters for these and then included them in the results of listdevices, just like 'results' is done.  Seems to work fine though I am not sure it's the best way.  Could these types of status be added to the official rpc interface?


I have added accepted and rejected fields to the listdevices RPC interface.

The number of shares that were not sent to the server for any reason can be found by:

shares not sent = results - (accepted + rejected)

great, that means we can throw away all the custom stuff bamt used to have to hack into phoenix, very nice.  also kudos on using a standard interface.. json/rpc might not be everyone's favorite thing but its a standard and its pleasant to deal with.

the only area where phoenix2 does not now provide as good or better info than other miners is with pool summary data...  this isn't something I've ever worried about with original phoenix since it basically supported only the one, or at best a single backup.  However now that phoenix2 is supporting lots of backup pools, it might be worth consideration.  some sort of "listpools" similar to listdevices that reported per pool info.. accept/reject/connection errors, latency that kind of thing might be nice.  If you're interested and it helps, I could hack such a thing together.





Title: Re: Phoenix 2 beta discussion
Post by: aaa801 on March 03, 2012, 03:44:58 AM
[03/03/2012 03:43:57] Welcome to Phoenix v2.0.0-rc2
[03:43:57] Failed to load plugin "opencl"
[03:43:57] Failed to load plugin "phatk2"


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on March 03, 2012, 09:58:16 AM
[03/03/2012 03:43:57] Welcome to Phoenix v2.0.0-rc2
[03:43:57] Failed to load plugin "opencl"
[03:43:57] Failed to load plugin "phatk2"


Those 3 lines are not enough information to determine the cause of the problem.

Could you provide the following:
Which OS?
Are you using the compiled binaries or running phoenix from source?
Which GPU(s) do you have?
Can you post a copy of your phoenix.cfg? (remember to edit out user/password for backend and RPC)


Title: Re: Phoenix 2 beta discussion
Post by: aaa801 on March 03, 2012, 10:38:22 AM
[03/03/2012 03:43:57] Welcome to Phoenix v2.0.0-rc2
[03:43:57] Failed to load plugin "opencl"
[03:43:57] Failed to load plugin "phatk2"


Those 3 lines are not enough information to determine the cause of the problem.

Could you provide the following:
Which OS?
Are you using the compiled binaries or running phoenix from source?
Which GPU(s) do you have?
Can you post a copy of your phoenix.cfg? (remember to edit out user/password for backend and RPC)



Which OS? Windows 7 64bit
Are you using the compiled binaries or running phoenix from source? binaries
Which GPU(s) do you have? 5850
Can you post a copy of your phoenix.cfg? (remember to edit out user/password for backend and RPC)

Code:
[general]
verbose = True
autodetect = +cl -cpu # The rightmost parameter takes precedence. This enables all OpenCL devices, except those that are CPUs.
backend = http://localhost:9332 # URL format is exactly as it was in Phoenix 1
backups = URL1 URL2 URL3 URL4 # Any number of backup backends (space-separated) to use in case the primary backend goes down.

[web]
password = ### # Set an RPC password to keep people from messing with your miners.

AGGRESSION = 12
bfi_int = True
vectors = True
FASTLOOP=FALSE
WORKSIZE=256



Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on March 03, 2012, 11:46:07 AM
*Sigh* See, the problem is people just copy paste. They don't try to understand what a config file does or what you should put in there. Every time I see that autodetect line, I just facepalm.


Title: Re: Phoenix 2 beta discussion
Post by: aaa801 on March 03, 2012, 12:35:56 PM
*Sigh* See, the problem is people just copy paste. They don't try to understand what a config file does or what you should put in there. Every time I see that autodetect line, I just facepalm.
Well maybe if there was some actual sample code or less assholeism from forum members itd be easier to get working..?


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on March 03, 2012, 12:51:53 PM
*Sigh* See, the problem is people just copy paste. They don't try to understand what a config file does or what you should put in there. Every time I see that autodetect line, I just facepalm.
Well maybe if there was some actual sample code or less assholeism from forum members itd be easier to get working..?

You mean the example on the very first post of the very first page?  ::) It's an example. It's not meant for you to copy paste. Understand it. Learn from it. Make your own to best suit your needs. I don't know what hardware you have or what parameters best suit your needs, only you do.


Title: Re: Phoenix 2 beta discussion
Post by: aaa801 on March 03, 2012, 01:01:10 PM
*Sigh* See, the problem is people just copy paste. They don't try to understand what a config file does or what you should put in there. Every time I see that autodetect line, I just facepalm.
Well maybe if there was some actual sample code or less assholeism from forum members itd be easier to get working..?

You mean the example on the very first post of the very first page?  ::) It's an example. It's not meant for you to copy paste. Understand it. Learn from it. Make your own to best suit your needs. I don't know what hardware you have or what parameters best suit your needs, only you do.


I put in the parameters from my other miner that is working fine
the fact that this cant load the freking plugins would mean that its fuck all to do with the config wouldnt it.


Title: Re: Phoenix 2 beta discussion
Post by: TurdHurdur on March 03, 2012, 08:22:59 PM
[03/03/2012 03:43:57] Welcome to Phoenix v2.0.0-rc2
[03:43:57] Failed to load plugin "opencl"
[03:43:57] Failed to load plugin "phatk2"

What cwd are you running it from?


Title: Re: Phoenix 2 beta discussion
Post by: aaa801 on March 04, 2012, 05:38:38 AM
the root of the phoenix 2 folder, where phoenix.exe is located


Title: Re: Phoenix 2 beta discussion
Post by: d3m0n1q_733rz on March 12, 2012, 05:58:39 AM
*Sigh* See, the problem is people just copy paste. They don't try to understand what a config file does or what you should put in there. Every time I see that autodetect line, I just facepalm.
Well maybe if there was some actual sample code or less assholeism from forum members itd be easier to get working..?

You mean the example on the very first post of the very first page?  ::) It's an example. It's not meant for you to copy paste. Understand it. Learn from it. Make your own to best suit your needs. I don't know what hardware you have or what parameters best suit your needs, only you do.


I put in the parameters from my other miner that is working fine
the fact that this cant load the freking plugins would mean that its fuck all to do with the config wouldnt it.
Actually, it could mean that they changed the kernel directory on you.  You might have to move your kernels over to the new directory.


Title: Re: Phoenix 2 beta discussion
Post by: shackleford on March 14, 2012, 02:49:12 PM
I have been using this for a few weeks and I have noticed something odd but I don't know if it is just me. It seems like the longer I leave it open less shares get submitted back to my pool. The hash rate that the pools report based on returned work has generally been pretty accurate over time . However the longer I leave phoenix 2.0 open the lower it goes until I close and restart it. The lowest I have let it go was around 30% off the expected.  As soon as I restart it immediately goes up to where I would expect it (and correlating share of block). The miner always reports the expected full speed hash speed.

This is not a big deal as long as I remember to restart it every few days but thought I would mention it so people could tell me I was crazy.


Title: Re: Phoenix 2 beta discussion
Post by: shackleford on March 18, 2012, 01:05:51 AM
I have been using this for a few weeks and I have noticed something odd but I don't know if it is just me. It seems like the longer I leave it open less shares get submitted back to my pool. The hash rate that the pools report based on returned work has generally been pretty accurate over time . However the longer I leave phoenix 2.0 open the lower it goes until I close and restart it. The lowest I have let it go was around 30% off the expected.  As soon as I restart it immediately goes up to where I would expect it (and correlating share of block). The miner always reports the expected full speed hash speed.

This is not a big deal as long as I remember to restart it every few days but thought I would mention it so people could tell me I was crazy.


NM, one of my cards was messing up and not hashing even though it was somehow counting towords the total. Running 1.75 for each gpu  stalls one miner, looks like you can't go by what is being reported for the hash rate. The missing 30% matches up with the cards hashing power.Lowered the OC 10mhz and all is well.


Title: Re: Phoenix 2 beta discussion
Post by: flinder on March 25, 2012, 02:47:14 PM
Hello,

i tried Phoenix 2 beta RC2 today. After some configuration I get a higher Hashrate than with Phoenix 1.
But I have one question to the output? What does "rolling time" means? I get this output very often.

I have an ATI 6850 with the following setup:

[general]
verbose = True
autodetect = +cl -cpu
backend = http://xxx.xxx:xxx@api2.bitcoin.cz:8332

[web]
password = rpc_password

[cl:0:0]       
kernel = phatk2   
autoconfigure = false
bfi_int = true
vectors4 = true    
WORKSIZE = 128      
AGGRESSION = 11   
FASTLOOP = false

Thanks for the explanation!




Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on March 26, 2012, 09:23:41 AM
Hello,

i tried Phoenix 2 beta RC2 today. After some configuration I get a higher Hashrate than with Phoenix 1.
But I have one question to the output? What does "rolling time" means? I get this output very often.

I have an ATI 6850 with the following setup:

[general]
verbose = True
autodetect = +cl -cpu
backend = http://xxx.xxx:xxx@api2.bitcoin.cz:8332

[web]
password = rpc_password

[cl:0:0]       
kernel = phatk2   
autoconfigure = false
bfi_int = true
vectors4 = true    
WORKSIZE = 128      
AGGRESSION = 11   
FASTLOOP = false

Thanks for the explanation!


"Rolling Time" is a debug output that indicates when Phoenix increments the timestamp on a WorkUnit. This reduces the load on the pool server by generating more work locally instead of asking for more. This will only occur on pool servers which send the X-Roll-NTime header.


Title: Re: Phoenix 2 beta discussion
Post by: flinder on March 26, 2012, 11:05:01 AM
Quote
"Rolling Time" is a debug output that indicates when Phoenix increments the timestamp on a WorkUnit. This reduces the load on the pool server by generating more work locally instead of asking for more. This will only occur on pool servers which send the X-Roll-NTime header.

First thanx for the explanation.
Now when I know what it means, I found this feature on the website of bitcoin.cz (Slush's Pool) to. He has implemented this feature to his pool.

But maybe there is a problem. Or better to say it seems for me like I have a problem.
With Phoenix 2 I have a higher Hashrate on my system. But I get lower average BTC in the pool for my work on the last 2 days.

The pay out system on bitcoin.cz is in the way that the last shares are more important than the first ones.
Could it be, because of this proportional system and the fact X-Roll-NTime reduces the load on the pool server, that I submit hashes in longer distances? But you will get more BTC on bitcoin.cz when you are close to the moment, when the solution is found.

So this feature seems to be good for the pool, but maybe bad for me  ;)
And I have to think about the probability, that I also will get more BTC, when I sometimes will submit more datas close to the end.

But there is one question. Is it possible to disable this feature in the miner? Is there a setting I have to set on false?

Thanks for the help again!  :)


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on March 26, 2012, 08:56:39 PM
Quote
"Rolling Time" is a debug output that indicates when Phoenix increments the timestamp on a WorkUnit. This reduces the load on the pool server by generating more work locally instead of asking for more. This will only occur on pool servers which send the X-Roll-NTime header.

First thanx for the explanation.
Now when I know what it means, I found this feature on the website of bitcoin.cz (Slush's Pool) to. He has implemented this feature to his pool.

But maybe there is a problem. Or better to say it seems for me like I have a problem.
With Phoenix 2 I have a higher Hashrate on my system. But I get lower average BTC in the pool for my work on the last 2 days.

The pay out system on bitcoin.cz is in the way that the last shares are more important than the first ones.
Could it be, because of this proportional system and the fact X-Roll-NTime reduces the load on the pool server, that I submit hashes in longer distances? But you will get more BTC on bitcoin.cz when you are close to the moment, when the solution is found.

So this feature seems to be good for the pool, but maybe bad for me  ;)
And I have to think about the probability, that I also will get more BTC, when I sometimes will submit more datas close to the end.

But there is one question. Is it possible to disable this feature in the miner? Is there a setting I have to set on false?

Thanks for the help again!  :)


A few things:

1. Measuring payout over a period of 2 days on any non pay-per-share pool is not enough data to make any conclusions. (pool luck makes a big difference)

2. Rolling time doesn't have any effect on sending results. You have the same odds of finding a share either way. (and thus the payout is not affected)

3. The pool doesn't care if a share is from locally generated rolltime work or work sent by the server. Either way it will count the same.

4. If you still want disable the feature you can modify your URL to set maxtime:
  http://name:password@api2.bitcoin.cz:8332/;maxtime=0


Title: Re: Phoenix 2 beta discussion
Post by: flinder on March 27, 2012, 12:28:33 PM
Quote
A few things:

1. Measuring payout over a period of 2 days on any non pay-per-share pool is not enough data to make any conclusions. (pool luck makes a big difference)

2. Rolling time doesn't have any effect on sending results. You have the same odds of finding a share either way. (and thus the payout is not affected)

3. The pool doesn't card if a share is from locally generated rolltime work or work sent by the server. Either way it will count the same.

4. If you still want disable the feature you can modify your URL to set maxtime:
  http://name:password@api2.bitcoin.cz:8332/;maxtime=0

First thanks for your answer!
But let me explain my thoughts again, because I think there is a uncertainty in my problem.

I work in Slush's Pool (bitcoin.cz). Because of pool hopping he implements in this pool a system, where older shares (from beginning of the round) has lower weight than newer shares, which demotivate cheater from switching between pools inside one round.
Matematically said, for every submitted share, pool perform:
 
Quote
score = score + exp(round_time/C)

So you will get relativly more BTC for one round, when you send shares close to the moment, when the solution is found and the round ends.
When I now submit shares in longer distances because of X-Roll-NTime, then the probability is higher that "a lot of other workers" send shares after me and gets more and more points for a round. So I'am interested to send results close to the end of a round, even if it are less shares. I will get proportionally more points for it.

For me it seems to be beeter to send shares more often to increase the odd, to be close to the end of a round and to get more points relativly to the others. It is an exponential function with the time. You said in your second point correctly, the odds of finding a share is the same, but the points I get for the shares depends on the time when I send. This is the way I understood the payment in this special pool (current hashrate: 1430.657 Ghash/s).

With your fourth point you gave me an explanation how to disable the feature. And after some rounds today it seems to be, that the average BTC for each round is higher, in each case closer together and the fluctuation in earnings per round seems smaller like yesterday. In any case, it feels like it. ;)

So I'am happy now :) , higher hashrate with Phoenix 2.0 and a higher average BTC for each round.

Thank you again for solving my problem!


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on March 29, 2012, 01:04:56 PM
Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on March 30, 2012, 07:59:47 PM
Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.

I need more information to isolate the problem.

Please test RC2 with the kernels from RC1. I need to know if the problem is at the kernel level or something else.


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on March 31, 2012, 01:03:41 AM
Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.

I need more information to isolate the problem.

Please test RC2 with the kernels from RC1. I need to know if the problem is at the kernel level or something else.

You already fixed it though IIRC, you just never made a windows build for the fix.

Hmm, RC1 works flawlessly. I tried RC2 but it's bugged bad? I thought it might have been incompatible with sdk 2.1 (wont hash at all), so I tried 2.6. It has a different error, but it hashes slow compared to 2.6, and I refuse to use 2.6 and be forced to use high memory clocks and waste power.

back to using rc1 until bug is fixed.

A fix for this bug has been pushed to the Git repo.

https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py


Title: Re: Phoenix 2 beta discussion
Post by: jedi95 on March 31, 2012, 02:09:42 AM
Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.

I need more information to isolate the problem.

Please test RC2 with the kernels from RC1. I need to know if the problem is at the kernel level or something else.

You already fixed it though IIRC, you just never made a windows build for the fix.

Hmm, RC1 works flawlessly. I tried RC2 but it's bugged bad? I thought it might have been incompatible with sdk 2.1 (wont hash at all), so I tried 2.6. It has a different error, but it hashes slow compared to 2.6, and I refuse to use 2.6 and be forced to use high memory clocks and waste power.

back to using rc1 until bug is fixed.

A fix for this bug has been pushed to the Git repo.

https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py

That's part of the kernel, so it's drop-in compatible with RC2. Just replace the original __init__.py with the latest version from the repo.


Title: Re: Phoenix 2 beta discussion
Post by: ssateneth on March 31, 2012, 05:51:56 AM
Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.

I need more information to isolate the problem.

Please test RC2 with the kernels from RC1. I need to know if the problem is at the kernel level or something else.

You already fixed it though IIRC, you just never made a windows build for the fix.

Hmm, RC1 works flawlessly. I tried RC2 but it's bugged bad? I thought it might have been incompatible with sdk 2.1 (wont hash at all), so I tried 2.6. It has a different error, but it hashes slow compared to 2.6, and I refuse to use 2.6 and be forced to use high memory clocks and waste power.

back to using rc1 until bug is fixed.

A fix for this bug has been pushed to the Git repo.

https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py

That's part of the kernel, so it's drop-in compatible with RC2. Just replace the original __init__.py with the latest version from the repo.

Would that work for phatk2 kernel? I see its in the opencl folder and not phatk2 folder, so I don't know if they are compatible with each other.
Edit: Never mind. I chose to not question you and update it anyways, and lo and behold its hashing away on 2.1 sdk. Thanks. Too bad I didn't realize this over a month ago. Sorry for wasting your time <.<


Title: Re: Phoenix 2 beta discussion
Post by: blandead on March 31, 2012, 06:54:54 AM
Would you be interested in integrating my vectors3 method into phoenix 2?

I've been testing it with phoenix 2 lately and I'm getting some good results


Title: Re: Phoenix 2 beta discussion
Post by: kakobrekla on April 05, 2012, 09:39:43 AM
[07:39:47] Warning: work queue empty, miner is idle
[07:49:25] [Juniper 0] Result 00000000f4e9d2ab... REJECTED
[07:59:12] Server gave new work; passing to WorkQueue
[07:59:12] New block (WorkQueue)
[07:59:32] Warning: work queue empty, miner is idle
[08:09:03] Disconnected from server
[08:13:54] Connected to server
[08:13:54] Server gave new work; passing to WorkQueue
[08:13:54] New block (WorkQueue)
[08:14:14] Warning: work queue empty, miner is idle
[08:19:53] Disconnected from server
[08:29:26] Connected to server
[08:29:26] Server gave new work; passing to WorkQueue
[08:29:26] New block (WorkQueue)
[08:29:47] Warning: work queue empty, miner is idle
[08:39:03] Disconnected from server
[08:43:55] [Juniper 0] Result 00000000ef3e0789... REJECTED
[08:50:17] Couldn't connect to server, switching backend...
[08:59:28] Connected to server
[08:59:28] Server gave new work; passing to WorkQueue
[08:59:28] New block (WorkQueue)
[08:59:29] Primary backend is available, switching back...
[08:59:29] Disconnected from server
[08:59:48] Warning: work queue empty, miner is idle
[09:09:28] Connected to server
[09:09:28] Server gave new work; passing to WorkQueue
[09:09:48] Warning: work queue empty, miner is idle
[09:19:29] [Juniper 0] Result 0000000067b871b3... REJECTED
[09:29:54] [Juniper 0] Result 000000006d839047... REJECTED
[09:40:18] Disconnected from server
[09:50:18] Connected to server
[09:50:18] Server gave new work; passing to WorkQueue
[09:50:18] New block (WorkQueue)
[09:50:39] Warning: work queue empty, miner is idle
[10:00:19] Disconnected from server
[10:10:20] [Juniper 0] Result 0000000089992964... REJECTED
[10:20:20] Couldn't connect to server, switching backend...
[10:30:20] Connected to server
[10:30:20] Server gave new work; passing to WorkQueue
[10:30:20] New block (WorkQueue)
[10:30:21] Primary backend is available, switching back...
[10:30:21] Disconnected from server
[10:30:40] Warning: work queue empty, miner is idle
[10:41:39] Connected to server
[10:41:39] Server gave new work; passing to WorkQueue
[10:41:39] New block (WorkQueue)
[10:41:59] Warning: work queue empty, miner is idle
[10:59:04] Disconnected from server
[11:09:30] [Juniper 0] Result 00000000d21685c6... REJECTED
[11:20:19] [Juniper 0] Result 00000000f670e890... REJECTED
[11:31:40] Connected to server
[11:31:40] Server gave new work; passing to WorkQueue
[11:31:40] New block (WorkQueue)
[11:32:01] Warning: work queue empty, miner is idle
[0 Khash/s] [242 Accepted] [63 Rejected] [RPC (+LP)]


After some time it comes to this and I have to reset phoenix. Sucks if it happens in the beginning of the night.
Two pools are configured yet phoenix can't get its shit together and mine.

Anyone has an idea whats the deal with this? Other mining software does not exhibit this behavior.


Title: Re: Phoenix 2 beta discussion
Post by: ZPK on April 05, 2012, 11:54:33 AM
yeap this phoenix love random disconnect/connect