Bitcoin Forum
April 21, 2014, 12:13:37 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11
1  Bitcoin / Mining software (miners) / Re: Phoenix 2 Miner v2.0.0 on: April 24, 2012, 01:19:43 AM
Is there any documentation about how to use the JSON RPC?

See doc/rpc.txt:
https://github.com/phoenix2/phoenix/blob/master/doc/rpc.txt
2  Bitcoin / Mining software (miners) / Re: Phoenix - Efficient, fast, modular miner on: April 07, 2012, 08:45:51 AM
Phoenix 2.0.0 has been released as stable:
https://bitcointalk.org/index.php?topic=75786

Mods: Please sticky the new thread to replace this one
3  Bitcoin / Mining software (miners) / Phoenix 2 Miner v2.0.0 on: April 07, 2012, 08:43:08 AM
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 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.
  • 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.0
Windows binaries
Source code/Linux release (requires Python, Twisted, and PyOpenCL)

GitHub:
https://github.com/phoenix2/phoenix


Donations

1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU


Tools
OpenCL info script


Links
Phoenix 1.x
Multiminer thread
MMP protocol specifications
phatk/phatk2 kernel thread
Diapolo's diakgcn kernel
4  Other / CPU/GPU Bitcoin mining hardware / Re: GeForce GTX 680 are now available! Please post hashing results here. on: April 06, 2012, 08:31:00 PM
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:
Code:
[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.

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]
5  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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.
6  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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.
7  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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  Wink
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!  Smiley


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
8  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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.
9  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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)
10  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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)
11  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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
12  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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
13  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion on: February 22, 2012, 11:21:35 AM
Sounds pretty cool, thanks for the changes ... if only the Windows build would be available Cheesy.
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
14  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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.
15  Bitcoin / Project Development / Re: [BOUNTY - 10BTC] Web control panel for Phoenix 2 miner on: February 15, 2012, 08:44:49 AM
I will pledge 5 BTC.
16  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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 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.
17  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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.
18  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion on: February 11, 2012, 07:42:35 PM
Edited: my bad, don't forget "agression" != "aggression" Smiley

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
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.
19  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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]
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.
20  Bitcoin / Mining software (miners) / Re: Phoenix 2 beta discussion 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.
Pages: [1] 2 3 4 5 6 7 8 9 10 11
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!