Features- BFI_INT support - Improves performance by 5-20% on supported GPUs
- Efficient - Phoenix 2 doesn't discard any work unless it is invalid.
- X-Roll-NTime support - Reduces load on pool servers by generating more work locally.
- Free, open-source software - Phoenix 2 is available under the X11 license, and written in (fairly) well-documented and commented Python.
- Modular kernels - If someone releases a more efficient kernel for our miner, it's as simple as dropping in the new kernel and using it.
- Multiple device support - A single Phoenix 2 instance can mine on all the hardware in the system.
- Hardware autodetect - Phoenix 2 can automatically detect and configure hardware.
- 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 autodetectPhoenix 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 interfacePhoenix 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.
- backend - Sets the backend server. EX: http://user:password@example.com:8332
- backups - Sets the backup servers. EX: http://user2:password2@server2.com:8332 http://bitcoin:bitcoin@localhost:8332
- failback - Sets the interval to check the main server when on a backup server.
- logfile - Enable this option to log to a file.
- queuesize - Target/maximum size of queue.
- queuedelay - Seconds before work expires to request more work.
- ratesamples - Number of samples to average for hashrate reporting.
- statusinterval - Seconds between status bar updates.
- verbose - Enables verbose logging.
Global device settings- autoconfigure - Enables automatic configuration for the selected device.
- disabled - Disables mining on this device.
- kernel - Specifies which kernel to use for this device.
- name - Sets the name to use for this device.
- start_undetected - Sets if the kernel should start even if the device is not detected.
OpenCL/phatk2 Kernel settings- aggression - Sets the aggression. This allows you to control the kernel execution time to improve hashrate or reduce interface lag.
- bfi_int - Enables the BFI_INT instruction on this device. (only supported by ATI 5xxx and 6xxx)
- fastloop - Enables fast internal loop. This improves hashrate at lower aggression levels without introducing any additional interface lag.
- goffset - Enables OpenCL 1.1 global offset. This can improve hashrate on supported devices.(does nothing for phatk2)
- vectors - Enables 2-way vectors. (use this or vectors4, not both)
- vectors4 - Enables 4-way vectors. (use this or vectors, not both)
- worksize - Sets the worksize. Tweaking this setting may improve performance.
Download
Latest version: 2.0.0Windows binariesSource code/Linux release (requires Python, Twisted, and PyOpenCL) GitHub: https://github.com/phoenix2/phoenixDonations1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU ToolsOpenCL info scriptLinksPhoenix 1.xMultiminer threadMMP protocol specificationsphatk/phatk2 kernel threadDiapolo's diakgcn kernel
|
|
|
|
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: [cl:1:0]
kernel = opencl
name = GTX 680
disabled = False
worksize = 256
vectors = False
vectors4 = False
bfi_int = False
goffset = False
fastloop = True
aggression = 2 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. [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. 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. |
|
|
|
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. 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 |
|
|
|
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. |
|
|
|
[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) |
|
|
|
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) |
|
|
|
|
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. |
|
|
|
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: import jsonrpc
sp = jsonrpc.ServiceProxy('http://x:phoenix@localhost:7780')
sp.setconfig('general', 'backend', 'http://user:password@pool.com:8332')
This will cause Phoenix to switch to the new pool immediately. |
|
|
|
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. [general]
autodetect = +cl -cpu
backend = http://XYZ:XYZ@pool.bitlc.net
ratesamples = 100
verbose = true
[cl:0:0]
disabled = false
kernel = diakgcn
aggression = 12
goffset = true
vectors2 = true
vectors4 = false
vectors8 = false
worksize = 256
[cl:0:1]
disabled = false
kernel = diakgcn
aggression = 12
goffset = true
vectors2 = false
vectors4 = false
vectors8 = true
worksize = 128 Hashrate for each device is ~540 MH/s + 60 MH/s, which should lead to ~600 MH/s for the above config. Real displayed rate is only 114 MH/s, so it seems the kernel does not use the supplied settings for each device but perhaps uses only the last supplied parameters (here for [cl:0:1]. Could well be a problem of my init / kernel, but could also be a general problem. Any ideas? Dia I'm going to need more info to figure this one out. Multiple kernels is working fine on one of my rigs with a 5870 + 5830. Things to check: Can you try this using opencl and/or phatk2 kernels for both devices? What load % are you getting on each GPU? Is the CPU load % being maxed out? (perhaps a bug in the CPU detection code you submitted?) "autodetect = +cl -cpu" would use the CPU if the detection code doesn't work. |
|
|
|
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. |
|
|
|
|
Show Posts
.
