Phoenix 2 beta discussion

[m3ta]

Code:

[04:20:30] [Cypress 0] Error: Device returned hash with difficulty < 1

Unusable for P2Pool, then?

[1714794070]

1714794070

[1714794070]

1714794070

[1714794070]

1714794070

[1714794070]

1714794070

[1714794070]

1714794070

[ssateneth]

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.

[rjk]

Code:

[04:20:30] [Cypress 0] Error: Device returned hash with difficulty < 1

Unusable for P2Pool, then?

P2Pool shares are >1 not <1

[Diapolo]

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

[jedi95]

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.

[Diapolo]

I tried even a size of 4 for the queue, but does not seem to change things ... will make a short test with the default kernel.

Code:

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

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

That is with following config:

Code:

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

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

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

[cl:0:2]
disabled = true

[web]
disabled = true

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

Dia

[Diapolo]

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

[jedi95]

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

[Diapolo]

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

[CFSworks]

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

Dia

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

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

• Better kernel import mechanism (fix bug with phatk2 depending on opencl).
• Some semblance of a PluginInterface.
• jedi95 is making some kernel-level improvements
• Misc. bugfixes (got the Python-on-Linux installer working right, etc)
• Support for submitold (addresses some concerns 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.

[Schwede65]

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

Dia

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

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

• Better kernel import mechanism (fix bug with phatk2 depending on opencl).
• Some semblance of a PluginInterface.
• jedi95 is making some kernel-level improvements
• Misc. bugfixes (got the Python-on-Linux installer working right, etc)
• Support for submitold (addresses some concerns 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.

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

[CFSworks]

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.

[macbook-air]

Code:

[04:20:30] [Cypress 0] Error: Device returned hash with difficulty < 1

Unusable for P2Pool, then?

P2Pool shares are >1 not <1

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

[CFSworks]

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.

[mc_lovin]

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.

[mc_lovin]

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!

[niooron]

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

[ssateneth]

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.

[ssateneth]

Today's new GUI miner release has somewhat solved my problem.  

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

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

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

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

use 11.12 driver to avoid cpu bug on 2.1 sdk with multi-gpu. and yes, 2.1 install path and platform is entirely different from amd app (2.4+). you can have 2.1 and any one sdk from 2.4-2.6 installed on the same system. my config looks like this on my gamer system.

Code:

[general]
verbose = True
backend = http://1CxcPP8FVktppy4PHTYJKnZFqQeyZ3jArb:x@mining.eligius.st:8337

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

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

[web]
disable = true

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

[CFSworks]

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