Topic: Phoenix 2 beta discussion - page 3. (Read 58046 times)

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.

Phoenix 2.0.0-rc2 is now up.

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

The changes include:

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

Still to be implemented for release:

• Web control panel? I hope?
• PluginInterface so third-party non-kernel plugins (GPU management, GUI support, etc) can be easily created

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.

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.

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.

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

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!

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

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

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

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

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

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.

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.

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

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.

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...

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

No promises, but we might be able to get rc2 released in about 24 hours. Changes to be in rc2:

• Better kernel import mechanism (fix bug with phatk2 depending on opencl).
• Some semblance of a PluginInterface.
• jedi95 is making some kernel-level improvements
• Misc. bugfixes (got the Python-on-Linux installer working right, etc)
• Support for submitold (addresses some concerns forrestv had)
• Maybe backup pool support, if it's easy to tackle after this... otherwise we'll add it post-release

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

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

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 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.

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

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.


That is with following config:


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

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.

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

P2Pool shares are >1 not <1

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.