Phoenix - Efficient, fast, modular miner

[Chaseshaw]

1.7.0 on ubuntu (11.04) doesn't recognize ^C as escape. I can't reset anything!

Good fix on the disconnect issues. haven't had it anymore. though 1.7 seems to be about 1-2% slower than 1.6.4.

Keep up the good work!

[bal3wolf]

is their a way to make it go off at idle i tried  AGGRESSION=1 but then it wont use any gpu usage when idle even.

[slush]

Is phoenix still closing connection after LP broadcast? I see that as pretty annoying, because managing new connections after every LP broadcast are making unnecessary load on server...

[jedi95]

Is phoenix still closing connection after LP broadcast? I see that as pretty annoying, because managing new connections after every LP broadcast are making unnecessary load on server...

This shouldn't occur with 1.7.0.

[dirtycat]

Great miner! very good work.. I would like to add I am getting the exact same error about once every hour is this going to cause problems for the pool i connect to?

Thanks for still working on this! 1.7.0 seems to have some major bugs however; it keeps disconnecting/reconnecting/idling and also throws out error messages like this:

Code:

[04/11/2011 02:49:43] Phoenix v1.7.0 starting...
[04/11/2011 02:49:46] Connected to server
[04/11/2011 02:49:50] Result: f278c955 accepted
[04/11/2011 02:49:57] Disconnected from server
[04/11/2011 02:50:05] Result: 1ff83ef6 accepted
[359.95 Mhash/sec] [2 Accepted] [0 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "twisted\internet\defer.pyc", line 1076, in gotResult

  File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks

  File "twisted\internet\defer.pyc", line 388, in errback

  File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks

--- <exception caught here> ---
  File "twisted\internet\defer.pyc", line 542, in _runCallbacks

  File "minerutil\RPCProtocol.pyc", line 134, in errback

  File "minerutil\RPCProtocol.pyc", line 416, in _failure

  File "minerutil\RPCProtocol.pyc", line 227, in stop

  File "minerutil\RPCProtocol.pyc", line 57, in closeConnection

exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:50:12] Connected to server
[04/11/2011 02:50:22] Disconnected from server
[04/11/2011 02:50:36] Failed to connect, retrying...
[04/11/2011 02:50:36] Result: 84e0e226 rejected
[04/11/2011 02:50:45] Warning: work queue empty, miner is idle
[04/11/2011 02:50:47] Failed to connect, retrying...
[04/11/2011 02:50:47] Result: b27b0f3e rejected
[04/11/2011 02:51:02] Connected to server
[04/11/2011 02:51:13] Result: 2d5ce285 rejected
[04/11/2011 02:51:24] Result: 7cfcd8b4 rejected
[04/11/2011 02:51:37] Result: c6a5693f rejected
[04/11/2011 02:51:49] Disconnected from server
[04/11/2011 02:51:52] Result: c1db4b62 accepted
[04/11/2011 02:51:55] Result: 0a76485d accepted
[04/11/2011 02:51:59] Result: 2c040a77 accepted
[362.59 Mhash/sec] [5 Accepted] [5 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "twisted\internet\defer.pyc", line 1076, in gotResult

  File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks

  File "twisted\internet\defer.pyc", line 388, in errback

  File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks

--- <exception caught here> ---
  File "twisted\internet\defer.pyc", line 542, in _runCallbacks

  File "minerutil\RPCProtocol.pyc", line 134, in errback

  File "minerutil\RPCProtocol.pyc", line 416, in _failure

  File "minerutil\RPCProtocol.pyc", line 227, in stop

  File "minerutil\RPCProtocol.pyc", line 57, in closeConnection

exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:52:03] Connected to server
[04/11/2011 02:52:12] Disconnected from server
[04/11/2011 02:52:26] Connected to server
[04/11/2011 02:52:29] Result: 07de0847 accepted
[04/11/2011 02:52:36] Disconnected from server
[04/11/2011 02:52:45] Result: cec287f6 accepted
[363.54 Mhash/sec] [7 Accepted] [5 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "twisted\internet\defer.pyc", line 1076, in gotResult

  File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks

  File "twisted\internet\defer.pyc", line 388, in errback

  File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks

--- <exception caught here> ---
  File "twisted\internet\defer.pyc", line 542, in _runCallbacks

  File "minerutil\RPCProtocol.pyc", line 134, in errback

  File "minerutil\RPCProtocol.pyc", line 416, in _failure

  File "minerutil\RPCProtocol.pyc", line 227, in stop

  File "minerutil\RPCProtocol.pyc", line 57, in closeConnection

exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:52:50] Connected to server
[04/11/2011 02:53:00] Disconnected from server
[04/11/2011 02:53:01] Result: 893a5bf2 accepted
[04/11/2011 02:53:12] Failed to connect, retrying...
[04/11/2011 02:53:20] Result: db96c309 accepted
[04/11/2011 02:53:24] Warning: work queue empty, miner is idle
[04/11/2011 02:53:26] Connected to server
[04/11/2011 02:53:28] Result: ad7467bb accepted
[04/11/2011 02:53:37] Disconnected from server
[04/11/2011 02:53:40] Result: 0bc82c1e accepted
[04/11/2011 02:53:42] Result: 4f28a758 accepted
[04/11/2011 02:53:49] Failed to connect, retrying...
[04/11/2011 02:54:01] Warning: work queue empty, miner is idle
[04/11/2011 02:54:03] Connected to server
[04/11/2011 02:54:09] Result: a7930a31 accepted
[04/11/2011 02:54:14] Disconnected from server
[04/11/2011 02:54:22] Result: d86fb292 accepted
[04/11/2011 02:54:25] Result: 6b91137e rejected
[04/11/2011 02:54:25] Result: 491bf929 rejected
[355.15 Mhash/sec] [14 Accepted] [7 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "twisted\internet\defer.pyc", line 1076, in gotResult

  File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks

  File "twisted\internet\defer.pyc", line 388, in errback

  File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks

--- <exception caught here> ---
  File "twisted\internet\defer.pyc", line 542, in _runCallbacks

  File "minerutil\RPCProtocol.pyc", line 134, in errback

  File "minerutil\RPCProtocol.pyc", line 416, in _failure

  File "minerutil\RPCProtocol.pyc", line 227, in stop

  File "minerutil\RPCProtocol.pyc", line 57, in closeConnection

exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:54:29] Connected to server
[04/11/2011 02:54:33] Result: 558860c6 accepted
[04/11/2011 02:54:38] Disconnected from server
[04/11/2011 02:54:53] Connected to server
[354.42 Mhash/sec] [15 Accepted] [7 Rejected] [RPC (+LP)]

My command line was:

Code:

start "GPU 0" /min /affinity 0x08 phoenix.exe -q 2 -a 100 -u http://gpu0:pass@127.0.0.1:80/ -k phatk2 DEVICE=0 WORKSIZE=128 BFI_INT VECTORS FASTLOOP=false AGGRESSION=12

[jedi95]

Great miner! very good work.. I would like to add I am getting the exact same error about once every hour is this going to cause problems for the pool i connect to?

<removed to keep size reasonable>

My command line was:

Code:

start "GPU 0" /min /affinity 0x08 phoenix.exe -q 2 -a 100 -u http://gpu0:pass@127.0.0.1:80/ -k phatk2 DEVICE=0 WORKSIZE=128 BFI_INT VECTORS FASTLOOP=false AGGRESSION=12

What pool are you connecting to when this happens? I would like to figure out what is going on in more detail.

I have implemented a fix for the unhandled exception. You can download the new version here:
https://github.com/downloads/jedi95/Phoenix-Miner/phoenix-1.7.1.zip

There are no other changes in this version.

[dirtycat]

I have used it on slushs pool and also abcpool.
my exact command to startup is: phoenix -u http://user:pass@pool.abcpool.co:8332 -k phatk2 DEVICE=0 VECTORS BFI_INT AGGRESSION=7
ill give the fix a shot and see if anything happens from now on.

[TeaRex]

Thank you VERY MUCH for this fix!! The errors are completely gone and, judging from about 30 minutes of mining, the only remaining problem with the combination Phoenix 1.7.1 and cdhowie's proxy seems to be a relatively high number of rejects. Nothing earth shattering though so it might just have been bad luck. I'll keep trying and report back later.

[dirtycat]

same here works perfect havent had any more errors. 

[jedi95]

Version 1.7.2 released.

Changes:
 - Added rollntime support to RPC and MMP backends. The miner core doesn't support this yet, but it is planned for a future release.
 - Fixed a race condition in RPC that could result in disconnects.
 - Removed fetchRange() limitation: Work requests are no longer required to be multiples of 256. This makes it easier to implement some kernels. (3-way vectors for example)


Download
Latest version: 1.7.2
Windows binaries
Source code/Linux release (requires Python, Twisted, and PyOpenCL)

GitHub:
https://github.com/jedi95/Phoenix-Miner

[RobertRibbeck]

Version 1.7.2 released.

Changes:
 - Added rollntime support to RPC and MMP backends. The miner core doesn't support this yet, but it is planned for a future release.
 - Fixed a race condition in RPC that could result in disconnects.
 - Removed fetchRange() limitation: Work requests are no longer required to be multiples of 256. This makes it easier to implement some kernels. (3-way vectors for example)


Download
Latest version: 1.7.2
Windows binaries
Source code/Linux release (requires Python, Twisted, and PyOpenCL)

GitHub:
https://github.com/jedi95/Phoenix-Miner

call backs are counting as REJECTS even thought accepted on calback

[jedi95]

Version 1.7.2 released.

Changes:
 - Added rollntime support to RPC and MMP backends. The miner core doesn't support this yet, but it is planned for a future release.
 - Fixed a race condition in RPC that could result in disconnects.
 - Removed fetchRange() limitation: Work requests are no longer required to be multiples of 256. This makes it easier to implement some kernels. (3-way vectors for example)


Download
Latest version: 1.7.2
Windows binaries
Source code/Linux release (requires Python, Twisted, and PyOpenCL)

GitHub:
https://github.com/jedi95/Phoenix-Miner

call backs are counting as REJECTS even thought accepted on calback

So to make sure I'm understanding this correctly:
The miner itself is showing the shares as "accepted" but the server is showing them as rejects?

If this is the case, then I don't know what could be wrong. I tested both the MMP and RPC backends and verified that the servers were accepting the work. I need to know what you are connecting the miner to in order to attempt to reproduce the bug.

[RobertRibbeck]

Version 1.7.2 released.

Changes:
 - Added rollntime support to RPC and MMP backends. The miner core doesn't support this yet, but it is planned for a future release.
 - Fixed a race condition in RPC that could result in disconnects.
 - Removed fetchRange() limitation: Work requests are no longer required to be multiples of 256. This makes it easier to implement some kernels. (3-way vectors for example)


Download
Latest version: 1.7.2
Windows binaries
Source code/Linux release (requires Python, Twisted, and PyOpenCL)

GitHub:
https://github.com/jedi95/Phoenix-Miner

call backs are counting as REJECTS even thought accepted on calback

So to make sure I'm understanding this correctly:
The miner itself is showing the shares as "accepted" but the server is showing them as rejects?

If this is the case, then I don't know what could be wrong. I tested both the MMP and RPC backends and verified that the servers were accepting the work. I need to know what you are connecting the miner to in order to attempt to reproduce the bug.

other way around phoenix counts the callback share as a reject
deepbit counted them as accepted

[jedi95]

other way around phoenix counts the callback share as a reject
deepbit counted them as accepted

I can't seem to make this happen running directly from source or with the compiled binaries.

This is what I get:

Code:

C:\phoenix-1.7.2>phoenix.exe -u http://name@site.com_0:pass@deepbit.net:8332-k poclbm PLATFORM=1 DEVICE=0 VECTORS WORKSIZE=256 AGGRESSION=2
[01/01/2012 14:37:13] Phoenix v1.7.2 starting...
[01/01/2012 14:37:13] Connected to server
[01/01/2012 14:37:17] Result: 577a1849 accepted
[01/01/2012 14:37:54] Result: d7086c70 accepted
[01/01/2012 14:38:09] LP: New work pushed
[01/01/2012 14:40:13] Result: 6c9dac94 accepted
[01/01/2012 14:40:52] Result: 8597e915 accepted
[01/01/2012 14:41:29] Result: b471f52b accepted
[01/01/2012 14:43:05] Result: 7b804d65 accepted
[01/01/2012 14:43:20] Result: 6fa8cd29 accepted
[01/01/2012 14:43:41] Result: 0d44ad94 accepted
[01/01/2012 14:43:44] Result: d3257977 accepted
[01/01/2012 14:43:58] Result: ff050303 accepted
[01/01/2012 14:44:30] Result: 532bb58a accepted
[01/01/2012 14:44:48] Result: 601ae9a6 accepted
[01/01/2012 14:45:11] Result: 14ec7578 accepted
[01/01/2012 14:45:24] Result: 625a3fa9 accepted
[01/01/2012 14:46:47] Result: 2799a017 accepted
[01/01/2012 14:47:12] Result: 0cb8b48c accepted
[01/01/2012 14:47:23] Result: e51ebf99 accepted
[01/01/2012 14:47:31] Result: c70a50bb accepted
[01/01/2012 14:47:34] Result: 73235812 accepted
[01/01/2012 14:48:18] Result: c82089b9 accepted
[01/01/2012 14:48:42] Result: e85f85a8 accepted
[01/01/2012 14:49:23] Result: 2122b1b1 accepted
[01/01/2012 14:49:31] Result: 531f1a43 accepted
[01/01/2012 14:50:06] Result: baed89e0 accepted
[01/01/2012 14:50:09] Result: 5875f08c accepted
[01/01/2012 14:51:20] Result: 5db1e47a accepted
[01/01/2012 14:51:43] Result: a93c95dc accepted
[01/01/2012 14:52:23] Result: cb70f3bb accepted
[01/01/2012 14:52:28] Result: 71fa528c accepted
[138.48 Mhash/sec] [29 Accepted] [0 Rejected] [RPC (+LP)]

That's just a quick example, but I have other miners that have been running for a couple days on Deepbit without displaying this problem either.

[RobertRibbeck]

other way around phoenix counts the callback share as a reject
deepbit counted them as accepted

I can't seem to make this happen running directly from source or with the compiled binaries.

This is what I get:

Code:

C:\phoenix-1.7.2>phoenix.exe -u http://name@site.com_0:pass@deepbit.net:8332-k poclbm PLATFORM=1 DEVICE=0 VECTORS WORKSIZE=256 AGGRESSION=2
[01/01/2012 14:37:13] Phoenix v1.7.2 starting...
[01/01/2012 14:37:13] Connected to server
[01/01/2012 14:37:17] Result: 577a1849 accepted
[01/01/2012 14:37:54] Result: d7086c70 accepted
[01/01/2012 14:38:09] LP: New work pushed
[01/01/2012 14:40:13] Result: 6c9dac94 accepted
[01/01/2012 14:40:52] Result: 8597e915 accepted
[01/01/2012 14:41:29] Result: b471f52b accepted
[01/01/2012 14:43:05] Result: 7b804d65 accepted
[01/01/2012 14:43:20] Result: 6fa8cd29 accepted
[01/01/2012 14:43:41] Re
sult: 0d44ad94 accepted
[01/01/2012 14:43:44] Result: d3257977 accepted
[01/01/2012 14:43:58] Result: ff050303 accepted
[01/01/2012 14:44:30] Result: 532bb58a accepted
[01/01/2012 14:44:48] Result: 601ae9a6 accepted
[01/01/2012 14:45:11] Result: 14ec7578 accepted
[01/01/2012 14:45:24] Result: 625a3fa9 accepted
[01/01/2012 14:46:47] Result: 2799a017 accepted
[01/01/2012 14:47:12] Result: 0cb8b48c accepted
[01/01/2012 14:47:23] Result: e51ebf99 accepted
[01/01/2012 14:47:31] Result: c70a50bb accepted
[01/01/2012 14:47:34] Result: 73235812 accepted
[01/01/2012 14:48:18] Result: c82089b9 accepted
[01/01/2012 14:48:42] Result: e85f85a8 accepted
[01/01/2012 14:49:23] Result: 2122b1b1 accepted
[01/01/2012 14:49:31] Result: 531f1a43 accepted
[01/01/2012 14:50:06] Result: baed89e0 accepted
[01/01/2012 14:50:09] Result: 5875f08c accepted
[01/01/2012 14:51:20] Result: 5db1e47a accepted
[01/01/2012 14:51:43] Result: a93c95dc accepted
[01/01/2012 14:52:23] Result: cb70f3bb accepted
[01/01/2012 14:52:28] Result: 71fa528c accepted
[138.48 Mhash/sec] [29 Accepted] [0 Rejected] [RPC (+LP)]

That's just a quick example, but I have other miners that have been running for a couple days on Deepbit without displaying this problem either.

don't know what to tell you

maybe it nrollover shit

needless to say you & deepbit need to get it fixed

[Diapolo]

I'm using 1.7.2 with an own kernel version and 1/3 of the shares for my 6550D (A8-3850 APU) are rejected with:

Code:

[07/01/2012 16:15:34] Reject reason: unknown-work
[07/01/2012 16:15:34] Result 00000000ab246f85... rejected

What does this mean? Agression to high? Is the valid nonce invalid, because processing took too long?
My command line is:

Code:

-a 50 -k phatk AGGRESSION=12 DEVICE=1 FASTLOOP=false VECTORS2 WORKSIZE=64

Code:

[65.86 Mhash/sec] [103 Accepted] [33 Rejected] [RPC (+LP)]

Thanks,
Dia

Btw.: Anyone here, who is able to debug why I can't seem to get 3-component vectors working (see: http://www.mediafire.com/?r3n2m5s2y2b32d9 and use VECTORS3).

[jedi95]

I'm using 1.7.2 with an own kernel version and 1/3 of the shares for my 6550D (A8-3850 APU) are rejected with:

Code:

[07/01/2012 16:15:34] Reject reason: unknown-work
[07/01/2012 16:15:34] Result 00000000ab246f85... rejected

What does this mean? Agression to high? Is the valid nonce invalid, because processing took too long?
My command line is:

Code:

-a 50 -k phatk AGGRESSION=12 DEVICE=1 FASTLOOP=false VECTORS2 WORKSIZE=64

Code:

[65.86 Mhash/sec] [103 Accepted] [33 Rejected] [RPC (+LP)]

Thanks,
Dia

Btw.: Anyone here, who is able to debug why I can't seem to get 3-component vectors working (see: http://www.mediafire.com/?r3n2m5s2y2b32d9 and use VECTORS3).

It looks like you have run into the same fundamental problem I am trying to address before I can implement rollntime.

Essentially the server is rejecting your work because it is too old, not because kernel processing took too long. At 65 Mhash/sec, it will take just over a minute to process an entire WorkUnit of 2^32 nonces. Now, this work is not necessarily "stale" because it's from the current block and it meets the target specified by the server. This is made worse by the fact that Phoenix maintains a second WorkUnit in the queue by default. On a 5870 that can check the entire 2^32 space in 10-11 seconds, this is beneficial because it allows the miner to continue running during momentary connection disruptions or server load spikes. However, on hardware that takes over a minute to process 2^32 nonces, this can cause shares to be submitted from WorkUnits that are over 2 minutes old. This won't cause problems when the block changes because all work from previous block will be discarded immediately.

Rollntime introduces the same problems, since even very fast miners can now function for 30-60+ seconds on a single WorkUnit. The queue behavior needs to be adjusted to account for this. Most likely the solution will involve monitoring how much time is left until the miner runs out of work, and fetching more work when it falls below some value.

The message you are getting is sent by the pool server using x-reject-reason. I'm going to guess that the pool you are connecting to "forgets" about work it has assigned after some amount of time. (probably to save resources) I recommend trying other pools to see if you get the same behavior.

That said, aggression 12 on hardware doing only 65 Mhash/sec is probably not a good idea. Your kernel execution times are going to be something like ~4 seconds. This is problematic because you can't reasonably interrupt kernel executions to switch work. (eg: when the block changes) On average this is going to mean 2 seconds of wasted time per block (which amounts to a 0.33% loss) Try aggression 10 or so, which should limit this effect without much of a hashrate drop.

You can also use -q 0 to disable the queue entirely. This cuts your work age in half compared to the default of 1, but you might see the miner idling once per minute when it needs new work. At aggression 10 (kernel execution time 1 second) this shouldn't be a problem under normal cases. This allows for enough time to fetch new work before the miner runs out completely. However, this doesn't work at low aggression where the kernel execution time is a small fraction of a second.

[ummas]

Any1 can tell me where can i find fastest kernel to use witn 5870 ?
Currently i`m using stock 1.7 phatk2 from github with those param:
VACTORS AGGRESSION=8 BFI_INT FASTLOOP=false WORKSIZE=256

[Diapolo]

I'm using 1.7.2 with an own kernel version and 1/3 of the shares for my 6550D (A8-3850 APU) are rejected with:

Code:

[07/01/2012 16:15:34] Reject reason: unknown-work
[07/01/2012 16:15:34] Result 00000000ab246f85... rejected

What does this mean? Agression to high? Is the valid nonce invalid, because processing took too long?
My command line is:

Code:

-a 50 -k phatk AGGRESSION=12 DEVICE=1 FASTLOOP=false VECTORS2 WORKSIZE=64

Code:

[65.86 Mhash/sec] [103 Accepted] [33 Rejected] [RPC (+LP)]

Thanks,
Dia

Btw.: Anyone here, who is able to debug why I can't seem to get 3-component vectors working (see: http://www.mediafire.com/?r3n2m5s2y2b32d9 and use VECTORS3).

It looks like you have run into the same fundamental problem I am trying to address before I can implement rollntime.

Essentially the server is rejecting your work because it is too old, not because kernel processing took too long. At 65 Mhash/sec, it will take just over a minute to process an entire WorkUnit of 2^32 nonces. Now, this work is not necessarily "stale" because it's from the current block and it meets the target specified by the server. This is made worse by the fact that Phoenix maintains a second WorkUnit in the queue by default. On a 5870 that can check the entire 2^32 space in 10-11 seconds, this is beneficial because it allows the miner to continue running during momentary connection disruptions or server load spikes. However, on hardware that takes over a minute to process 2^32 nonces, this can cause shares to be submitted from WorkUnits that are over 2 minutes old. This won't cause problems when the block changes because all work from previous block will be discarded immediately.

Rollntime introduces the same problems, since even very fast miners can now function for 30-60+ seconds on a single WorkUnit. The queue behavior needs to be adjusted to account for this. Most likely the solution will involve monitoring how much time is left until the miner runs out of work, and fetching more work when it falls below some value.

The message you are getting is sent by the pool server using x-reject-reason. I'm going to guess that the pool you are connecting to "forgets" about work it has assigned after some amount of time. (probably to save resources) I recommend trying other pools to see if you get the same behavior.

That said, aggression 12 on hardware doing only 65 Mhash/sec is probably not a good idea. Your kernel execution times are going to be something like ~4 seconds. This is problematic because you can't reasonably interrupt kernel executions to switch work. (eg: when the block changes) On average this is going to mean 2 seconds of wasted time per block (which amounts to a 0.33% loss) Try aggression 10 or so, which should limit this effect without much of a hashrate drop.

You can also use -q 0 to disable the queue entirely. This cuts your work age in half compared to the default of 1, but you might see the miner idling once per minute when it needs new work. At aggression 10 (kernel execution time 1 second) this shouldn't be a problem under normal cases. This allows for enough time to fetch new work before the miner runs out completely. However, this doesn't work at low aggression where the kernel execution time is a small fraction of a second.

Thanks for this explanation, so I was on the right track. Are you trying to implement a solution for this currently or is there anything we / I can do to assist you there? Have you got an idea for the vec3 stuff not working?

I'm now trying AGRESSION=10, will report back after Phoenix ran a bit with that setting.

Edit 1: That's another error and has nothing to do with the discussed problem, right?

Code:

[08/01/2012 12:45:35] TypeError in RPC sendResult callback
[08/01/2012 12:45:35] Result 000000001fa9ed72... rejected

Thanks,
Dia

[jedi95]

Any1 can tell me where can i find fastest kernel to use witn 5870 ?
Currently i`m using stock 1.7 phatk2 from github with those param:
VACTORS AGGRESSION=8 BFI_INT FASTLOOP=false WORKSIZE=256

As far as I know, phatk2 is the fastest kernel for a 5870 on Phoenix when using SDK 2.4 or 2.5. I have only used 2.4 myself, so there might be a better option for SDK 2.5.

The settings to use depend on your memory clock. If you are running stock or near stock (1200MHz) then WORKSIZE=128 will give better performance. If you have downclocked your memory significantly (to 300MHz, for example) then WORKSIZE=256 will be faster.

If that 5870 isn't used for anything besides mining, I would recommend a bit higher AGGRESSION. (10 or so) If not, then I recommend that you don't disable FASTLOOP since it is beneficial at AGGRESSION 8 on a 5870.

Finally, it's VECTORS, not VACTORS

Thanks for this explanation, so I was on the right track. Are you trying to implement a solution for this currently or is there anything we / I can do to assist you there? Have you got an idea for the vec3 stuff not working?

I'm now trying AGRESSION=10, will report back after Phoenix ran a bit with that setting.

Edit 1: That's another error and has nothing to do with the discussed problem, right?

Code:

[08/01/2012 12:45:35] TypeError in RPC sendResult callback
[08/01/2012 12:45:35] Result 000000001fa9ed72... rejected

Thanks,
Dia

I am working on the problem, but I want to take the time to do it correctly instead of putting together a quick hacked-together fix. Thanks for the offer to help, but I think I have a pretty good idea of how I want to implement this.

I had a look at your VECTORS3 code, but I couldn't find any issues at first glance. Testing it is somewhat problematic because the computer I am working with only has a single GTX 580. All my 5870s are in dedicated mining systems which are not suitable for in-depth kernel debugging.

I can run VECTORS, VECTORS4, and no vectors on my GTX 580, but VECTORS3 gives me this:

Code:

--- <exception caught here> ---
  File "C:\Program Files (x86)\Python\lib\site-packages\twisted\python\threadpool.py", line 207, in_worker
    result = context.call(ctx, function, *args, **kwargs)
  File "C:\Program Files (x86)\Python\lib\site-packages\twisted\python\context.py", line 118, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "C:\Program Files (x86)\Python\lib\site-packages\twisted\python\context.py", line 81, in callWithContext
    return func(*args,**kw)
  File "kernels\phatk\__init__.py", line 442, in mineThread
    self.output_buf)
  File "C:\Program Files (x86)\Python\lib\site-packages\pyopencl\__init__.py", line 204, in kernel_call
    self.set_args(*args)
  File "C:\Program Files (x86)\Python\lib\site-packages\pyopencl\__init__.py", line 245, in kernel_set_args
    % (i+1, str(e)))
pyopencl.LogicError: when processing argument #16 (1-based): clSetKernelArg failed: invalid arg size