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] 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 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] 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] 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: 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:8332Title: 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] 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. ??? 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. This is what I've got exactly in my cfg file. lol Code: [cl:0:0] 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. 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. ??? 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. This is what I've got exactly in my cfg file. lol Code: [cl:0:0] 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. 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? The phatk2/opencl kernels recognize: Code: # [cl:0:0] vectors # Enable two-way vectors? [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] 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] 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? 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.http://dl.dropbox.com/u/9768004/error.png 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] 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). 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.Settings: Code: [cl:0:0] 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: 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] 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 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? The phatk2/opencl kernels recognize: Code: # [cl:0:0] vectors # Enable two-way vectors? [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] 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. :-[ 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};Code: // This file is in the public domain 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] 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 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 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] 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 should i change anything ? Code: [general] 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 SDK 2.4/2.5, Radeon 5xxx, 6xxx, Underclocked memory Code: kernel = phatk2 SDK 2.6, Radeon 5xxx, 6xxx, Normal memory (1GHz+) Code: kernel = phatk2 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 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 SDK 2.4/2.5, Radeon 5xxx, 6xxx, Underclocked memory Code: kernel = phatk2 SDK 2.6, Radeon 5xxx, 6xxx, Normal memory (1GHz+) Code: kernel = phatk2 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 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 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 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 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 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] 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] 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] 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: 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.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] 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 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 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 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 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 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? 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 That is with following config: Code: [general] 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:
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:
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? 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] 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:
Still to be implemented for release:
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] 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] 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 What cwd are you running it from?[03:43:57] Failed to load plugin "opencl" [03:43:57] Failed to load plugin "phatk2" 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. 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. 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
|