Bitcoin Forum
April 24, 2014, 05:50:53 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 5 [6] 7 8 9  All
  Print  
Author Topic: Phoenix 2 beta discussion  (Read 35247 times)
m3ta
Sr. Member
****
Offline Offline

Activity: 314



View Profile

Ignore
February 14, 2012, 04:21:46 AM
 #101

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

Unusable for P2Pool, then?

Why the frell so many retards spell "ect" as an abbreviation of "Et Cetera"? "ETC", DAMMIT! http://en.wikipedia.org/wiki/Et_cetera

Host:/# rm -rf /var/forum/trolls
1398318653
Hero Member
*
Offline Offline

Posts: 1398318653

View Profile Personal Message (Offline)

Ignore
1398318653
Reply with quote  #2

1398318653
Report to moderator
Unbeatable Service & Product Support
Grab Your Miners at GAWMiners.com
Order Before April 25th to receive
Double your Hashing Power for 1 week!

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1398318653
Hero Member
*
Offline Offline

Posts: 1398318653

View Profile Personal Message (Offline)

Ignore
1398318653
Reply with quote  #2

1398318653
Report to moderator
1398318653
Hero Member
*
Offline Offline

Posts: 1398318653

View Profile Personal Message (Offline)

Ignore
1398318653
Reply with quote  #2

1398318653
Report to moderator
ssateneth
Hero Member
*****
Offline Offline

Activity: 1022



View Profile

Ignore
February 14, 2012, 05:07:33 AM
 #102

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.

If I helped you, please consider donating some BTC my way! 1FVLZTwSiAsf9z9dLZcfEuBY59HQprFJwQ
I am a long time trusted user: Bitcointalk forum trust ratings, Bitcoin-OTC Ratings, eBay Feedback, and Localbitcoins public profile.
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile

Ignore
February 14, 2012, 05:08:44 AM
 #103

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

Unusable for P2Pool, then?
P2Pool shares are >1 not <1 Wink

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
February 14, 2012, 02:51:33 PM
 #104

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

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
jedi95
Full Member
***
Offline Offline

Activity: 219


View Profile

Ignore
February 14, 2012, 05:24:35 PM
 #105

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.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
February 14, 2012, 05:29:10 PM
 #106

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

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
February 14, 2012, 05:39:08 PM
 #107

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

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
jedi95
Full Member
***
Offline Offline

Activity: 219


View Profile

Ignore
February 15, 2012, 04:44:26 AM
 #108

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

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
February 15, 2012, 05:46:30 AM
 #109

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 Smiley ... when can we test the next release?
Thanks for your hard work on that long standing issue jedi!

Dia

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
CFSworks
Member
**
Offline Offline

Activity: 63


View Profile

Ignore
February 15, 2012, 07:12:59 AM
 #110


Very nice, now that are pretty good news Smiley ... 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. Grin

Phoenix Miner developer

PGP/GPG key: FC5461A3
Personal donations: 1Abq88sPz2MjH4Yi8yZVCbfu1ZXRSP7id5
Schwede65
Sr. Member
****
Offline Offline

Activity: 300


View Profile

Ignore
February 15, 2012, 08:29:24 AM
 #111


Very nice, now that are pretty good news Smiley ... 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. Grin

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
Member
**
Offline Offline

Activity: 63


View Profile

Ignore
February 15, 2012, 08:50:09 AM
 #112

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

Phoenix Miner developer

PGP/GPG key: FC5461A3
Personal donations: 1Abq88sPz2MjH4Yi8yZVCbfu1ZXRSP7id5
macbook-air
Full Member
***
Offline Offline

Activity: 121


View Profile

Ignore
February 18, 2012, 10:43:35 PM
 #113

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

Unusable for P2Pool, then?
P2Pool shares are >1 not <1 Wink

No. The initial difficulty is slightly < 1, at 0.999985.
CFSworks
Member
**
Offline Offline

Activity: 63


View Profile

Ignore
February 18, 2012, 11:33:25 PM
 #114

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.

Phoenix Miner developer

PGP/GPG key: FC5461A3
Personal donations: 1Abq88sPz2MjH4Yi8yZVCbfu1ZXRSP7id5
mc_lovin
Hero Member
*****
Offline Offline

Activity: 938


www.bitcointrading.com


View Profile WWW

Ignore
February 19, 2012, 08:09:00 PM
 #115

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
Hero Member
*****
Offline Offline

Activity: 938


www.bitcointrading.com


View Profile WWW

Ignore
February 19, 2012, 11:12:37 PM
 #116

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
Full Member
***
Offline Offline

Activity: 190


View Profile

Ignore
February 20, 2012, 02:50:42 AM
 #117

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

14dxwuQwkQiLbZjJFfciZ26xSGdRU5mKEp
ssateneth
Hero Member
*****
Offline Offline

Activity: 1022



View Profile

Ignore
February 20, 2012, 11:16:05 AM
 #118

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.

If I helped you, please consider donating some BTC my way! 1FVLZTwSiAsf9z9dLZcfEuBY59HQprFJwQ
I am a long time trusted user: Bitcointalk forum trust ratings, Bitcoin-OTC Ratings, eBay Feedback, and Localbitcoins public profile.
ssateneth
Hero Member
*****
Offline Offline

Activity: 1022



View Profile

Ignore
February 20, 2012, 11:17:11 AM
 #119

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.

If I helped you, please consider donating some BTC my way! 1FVLZTwSiAsf9z9dLZcfEuBY59HQprFJwQ
I am a long time trusted user: Bitcointalk forum trust ratings, Bitcoin-OTC Ratings, eBay Feedback, and Localbitcoins public profile.
CFSworks
Member
**
Offline Offline

Activity: 63


View Profile

Ignore
February 22, 2012, 10:19:30 AM
 #120

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

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

Phoenix Miner developer

PGP/GPG key: FC5461A3
Personal donations: 1Abq88sPz2MjH4Yi8yZVCbfu1ZXRSP7id5
Pages: 1 2 3 4 5 [6] 7 8 9  All
  Print  
 
Jump to:  

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!