RPC interface - Phoenix 2 can be monitored or controlled remotely using the RPC interface.

Config file - All user settings are stored in a simple config file.

Backup pool support - You can specify any number of backup pools in the config file

Supports RPC w/LP and MMP

Device autodetect

Phoenix 2 can automatically detect and configure all supported devices in the system. This can be configured via the global config option.

Autodetect can be specified by device class. With the default kernels Phoenix 2 support 3 classes of device: OpenCL (cl), CPU (cpu), and CUDA (cuda)

You can set the autodetect to only use certain devices. For example, the following setting will enable autodetect on all OpenCL devices except those which are CPUs or Nvidia GPUs (CUDA)autodetect = +cl -cpu -cuda

Each device is given a unique device ID. For OpenCL the format works like this:[class:platform:device]

So [cl:0:0] refers to OpenCL device 0 of platform 0.

[cpu:0] Is a generic identifier for the CPU.

JSON-RPC interface

Phoenix 2 has a built-in JSON-RPC server that allows remote monitoring and control of the miner. In the future this will be expanded to include a web interface.

bind - IP to bind the RPC server to.

disabled - Disables the RPC server.

logbuffer - The number of logs to return in the getlogs() call.

password - Password for the RPC server. Default is phoenix.

port - Port to use for the RPC server. Default is 7780.

root - Root directory for the web server.

Global settings

autodetect - Sets which classes of devices should be automatically detected.

GTX 680 mining does work but the performance is very disappointing at the moment. I think there may be some gains from drivers in the future though, since I'm only showing ~70% power usage. However, I highly doubt the GTX 680 will ever be competitive as a mining card.

Showing 123.40 Mhash/sec in Phoenix 2.0.0 with the following settings:

Vectors seem to reduce performance. Enabling goffset will cause the miner to error out and exit after about a minute. GPU clock was a constant 1241MHz for the test. (using +144 offset) Maximum load temperature was 67 C.

Code:

[04/06/2012 14:26:27] Welcome to Phoenix v2.0.0[14:26:27] Connected to server[14:26:27] Server gave new work; passing to WorkQueue[14:26:27] New block (WorkQueue)[14:26:27] Server gave new work; passing to WorkQueue[14:26:31] [GTX 680] Result 00000000963d2b3a... ACCEPTED[14:27:01] [GTX 680] Result 00000000a91cf2e1... ACCEPTED[14:27:02] Server gave new work; passing to WorkQueue[14:27:04] [GTX 680] Result 00000000dca6829f... ACCEPTED[14:27:12] [GTX 680] Result 00000000747b6cd5... ACCEPTED[14:27:15] [GTX 680] Result 000000005d990449... ACCEPTED[14:27:27] Server gave new work; passing to WorkQueue[14:27:32] [GTX 680] Result 0000000021cd0601... ACCEPTED[14:28:02] Server gave new work; passing to WorkQueue[14:28:27] Server gave new work; passing to WorkQueue[14:28:28] [GTX 680] Result 00000000db036548... ACCEPTED[14:28:51] Server gave new work; passing to WorkQueue[14:28:51] New block (WorkQueue)[14:28:52] Server gave new work; passing to WorkQueue[14:29:03] [GTX 680] Result 0000000057bdfa90... ACCEPTED[14:29:26] Server gave new work; passing to WorkQueue[14:29:52] Server gave new work; passing to WorkQueue[14:30:04] [GTX 680] Result 0000000093be9bbe... ACCEPTED[123.40 Mhash/s] [9 Accepted] [0 Rejected] [MMP]

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.

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.

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

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.

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

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)

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:

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.

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.

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.

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.

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.

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:

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.

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.

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.