Bitcoin Forum
March 28, 2024, 10:32:57 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 [53] 54 55 56 57 »
  Print  
Author Topic: Phoenix - Efficient, fast, modular miner  (Read 760531 times)
Diapolo
Hero Member
*****
Offline Offline

Activity: 769
Merit: 500



View Profile WWW
January 08, 2012, 11:43:15 AM
 #1041

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

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
1711621977
Hero Member
*
Offline Offline

Posts: 1711621977

View Profile Personal Message (Offline)

Ignore
1711621977
Reply with quote  #2

1711621977
Report to moderator
1711621977
Hero Member
*
Offline Offline

Posts: 1711621977

View Profile Personal Message (Offline)

Ignore
1711621977
Reply with quote  #2

1711621977
Report to moderator
No Gods or Kings. Only Bitcoin
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711621977
Hero Member
*
Offline Offline

Posts: 1711621977

View Profile Personal Message (Offline)

Ignore
1711621977
Reply with quote  #2

1711621977
Report to moderator
1711621977
Hero Member
*
Offline Offline

Posts: 1711621977

View Profile Personal Message (Offline)

Ignore
1711621977
Reply with quote  #2

1711621977
Report to moderator
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
January 08, 2012, 11:50:11 AM
Last edit: January 08, 2012, 04:28:27 PM by jedi95
 #1042

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

Phoenix Miner developer

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

Activity: 769
Merit: 500



View Profile WWW
January 08, 2012, 12:24:52 PM
 #1043

If NVIDIA has OpenCL 1.1 drivers, they should support uint3 ... but as I observed, too, Phoenix crashes in
Code:
self.kernel.search(...)
. Perhaps a certain parameter is not valid there. I had
Code:
self.size = (nonceRange.size / rateDivisor) / self.iterations
in my mind, because for VECTORS3 rateDivisor is 3 and so self.size is not correct, because nonceRange.size is perhaps not dividable by 3?

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
TeaRex
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
January 08, 2012, 12:42:42 PM
 #1044

You can also use -q 0 to disable the queue entirely.

Hmmm... at -q 0 Phoenix (current git running on Windows 7 x64, 64-bit Python 2.7.2) just keeps complaining that the queue is empty and never starts any actual mining.

The queue issue seems to be the reason why I get relatively high amounts of rejects when running against a local proxy; the proxy adds another layer of pre-fetching which of course makes the issue worse (and which you, jedi95, aren't responsible for at all).

*Image Removed*
I'm not asking for donations, but if you think YOUR post is deserving a donation FROM me, send me a message.
Diapolo
Hero Member
*****
Offline Offline

Activity: 769
Merit: 500



View Profile WWW
January 08, 2012, 01:37:41 PM
 #1045

You can also use -q 0 to disable the queue entirely.

Hmmm... at -q 0 Phoenix (current git running on Windows 7 x64, 64-bit Python 2.7.2) just keeps complaining that the queue is empty and never starts any actual mining.

The queue issue seems to be the reason why I get relatively high amounts of rejects when running against a local proxy; the proxy adds another layer of pre-fetching which of course makes the issue worse (and which you, jedi95, aren't responsible for at all).

I can confirm this, -q 0 is a no got currently.

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
ummas
Sr. Member
****
Offline Offline

Activity: 274
Merit: 250


View Profile
January 08, 2012, 03:30:55 PM
 #1046

@jedi95
 Sorry for my error, i have mssspeled. Of course i ment VECTORS.
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
January 08, 2012, 04:27:24 PM
 #1047

You can also use -q 0 to disable the queue entirely.

Hmmm... at -q 0 Phoenix (current git running on Windows 7 x64, 64-bit Python 2.7.2) just keeps complaining that the queue is empty and never starts any actual mining.

The queue issue seems to be the reason why I get relatively high amounts of rejects when running against a local proxy; the proxy adds another layer of pre-fetching which of course makes the issue worse (and which you, jedi95, aren't responsible for at all).

I can confirm this, -q 0 is a no got currently.

Dia

Sorry about that, I forgot that -q 0 only works in my current development version. It's an ugly workaround so I can test some things for rollntime.

The other solution is to use an askrate, which will reduce the problem.

Askrate can be specified by using this format for HTTP connections:
http://login:password@poolname.com:8332/;askrate=20

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
Elder III
Sr. Member
****
Offline Offline

Activity: 1246
Merit: 274


View Profile
January 08, 2012, 07:13:05 PM
 #1048

Using Phoenix 1.72 with 12.1 Preview drivers and 2.6 SDK - poclbm Aggression 7 - Worksize 64 - I'm getting ~433 mhash on my HD 6970 at Stock settings and voltage.... I'm delighted with those results, esp. considering that it's not using 100% of a CPu core now either. Smiley 
Diapolo
Hero Member
*****
Offline Offline

Activity: 769
Merit: 500



View Profile WWW
January 08, 2012, 09:08:35 PM
 #1049

Using Phoenix 1.72 with 12.1 Preview drivers and 2.6 SDK - poclbm Aggression 7 - Worksize 64 - I'm getting ~433 mhash on my HD 6970 at Stock settings and voltage.... I'm delighted with those results, esp. considering that it's not using 100% of a CPu core now either. Smiley  

poclbm kernel is at least 10 MH/s slower than my phatk version on my system with 6950, strange.

@jedi: Any reason to not use the latest pyOpenCL version for Phoenix? Perhaps there lies the vec3 problem? I read a bit in it's documentation and it seems a few commands Phoenix uses are now deprecated.

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Elder III
Sr. Member
****
Offline Offline

Activity: 1246
Merit: 274


View Profile
January 08, 2012, 11:11:58 PM
 #1050

Using Phoenix 1.72 with 12.1 Preview drivers and 2.6 SDK - poclbm Aggression 7 - Worksize 64 - I'm getting ~433 mhash on my HD 6970 at Stock settings and voltage.... I'm delighted with those results, esp. considering that it's not using 100% of a CPu core now either. Smiley  

poclbm kernel is at least 10 MH/s slower than my phatk version on my system with 6950, strange.



I was surprised to, as it seems that most people are using phatk or phatk2.  I haven't mined with that particular card (it's my gaming machine) in about 3 months, but I never got anything over 390-395 before, using GUIMiner.  I decided to mine again with it and was only getting ~366 mhash, so I tried out phoenix 1.72 and after a little tinkering and testing had my jaw drop when I saw it cranking out 433 or so mhash... going strong for over 24 hrs now too. Smiley
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
January 08, 2012, 11:51:39 PM
 #1051

Using Phoenix 1.72 with 12.1 Preview drivers and 2.6 SDK - poclbm Aggression 7 - Worksize 64 - I'm getting ~433 mhash on my HD 6970 at Stock settings and voltage.... I'm delighted with those results, esp. considering that it's not using 100% of a CPu core now either. Smiley  

poclbm kernel is at least 10 MH/s slower than my phatk version on my system with 6950, strange.

@jedi: Any reason to not use the latest pyOpenCL version for Phoenix? Perhaps there lies the vec3 problem? I read a bit in it's documentation and it seems a few commands Phoenix uses are now deprecated.

Dia

I know for a fact that uint3 vectors works under this version of pyOpenCL. I have been able to get the stock phatk to run with uint3 vectors enabled. The problems only occurs when I try to adjust the rateDivisor in the Python portion of the kernel. Dividing 2^N by 3 always has a remainder, so you end up sending bad work to the kernel.

This should at least give you a starting point:
https://github.com/downloads/jedi95/Phoenix-Miner/kernel.cl

The only change I made to the Python portion of the kernel is setting it to pass -DVECTORS3 to the compiler. Also note that without changing the rateDivisor your reported hashrate is going to be 2/3 of the actual value. Obviously this won't work well for mining as-is, but it at least it demonstrates that uint3 vectors work.

Phoenix Miner developer

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

Activity: 769
Merit: 500



View Profile WWW
January 09, 2012, 08:24:26 PM
 #1052

It really bothers me, the kernel you linked is one I know, it's an earlier version, who uses a different approach to compute the bases used in the kernel. Phateus introduced another method in his 2.x kernel, which I took and refined. But this seems to break uint3 support for my current version. Only other big difference I can think of is the use of an ulong as output buffer in my version, where your linked one still has an uint ... weird and it sucks ^^.

By the way, what have you added in 1.7.3? I downloaded and it works so far ... thanks.

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
January 10, 2012, 04:33:33 AM
 #1053

It really bothers me, the kernel you linked is one I know, it's an earlier version, who uses a different approach to compute the bases used in the kernel. Phateus introduced another method in his 2.x kernel, which I took and refined. But this seems to break uint3 support for my current version. Only other big difference I can think of is the use of an ulong as output buffer in my version, where your linked one still has an uint ... weird and it sucks ^^.

By the way, what have you added in 1.7.3? I downloaded and it works so far ... thanks.

Dia

I mainly intended to eliminate pyopencl as the source of the problem.

1.7.3 has a few fixes:
 - Updated phatk and poclbm to use bitselect() with BFI_INT disabled. This should help for GCN based GPUs (7970)
 - Modified WORKSIZE checking for poclbm, phatk, phatk2.
 - Disallowed -q 0 since it won't work correctly.

From what I have read bitselect() will properly compile to BFI_INT on GCN based GPUs without the crazy binary patching method required for VLIW5/VLIW4.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
RobertRibbeck
Full Member
***
Offline Offline

Activity: 221
Merit: 100


View Profile
January 11, 2012, 02:17:20 PM
 #1054

It really bothers me, the kernel you linked is one I know, it's an earlier version, who uses a different approach to compute the bases used in the kernel. Phateus introduced another method in his 2.x kernel, which I took and refined. But this seems to break uint3 support for my current version. Only other big difference I can think of is the use of an ulong as output buffer in my version, where your linked one still has an uint ... weird and it sucks ^^.

By the way, what have you added in 1.7.3? I downloaded and it works so far ... thanks.

Dia

I mainly intended to eliminate pyopencl as the source of the problem.

1.7.3 has a few fixes:
 - Updated phatk and poclbm to use bitselect() with BFI_INT disabled. This should help for GCN based GPUs (7970)
 - Modified WORKSIZE checking for poclbm, phatk, phatk2.
 - Disallowed -q 0 since it won't work correctly.

From what I have read bitselect() will properly compile to BFI_INT on GCN based GPUs without the crazy binary patching method required for VLIW5/VLIW4.

Crashes for me on win7 64bit

Please "Clear your browser cookies" then use http://bitcoinpyramid.com/r/3360 to Join BitCoin Pyramid
  use my referral & I'll refund a % of your first deposit back to your account
  Deposit .5 BTC or more and I'll give back 50% of what I receive

First Deposit of 1 BTC will get 75% of what I get back
Diapolo
Hero Member
*****
Offline Offline

Activity: 769
Merit: 500



View Profile WWW
January 11, 2012, 03:52:28 PM
 #1055

It really bothers me, the kernel you linked is one I know, it's an earlier version, who uses a different approach to compute the bases used in the kernel. Phateus introduced another method in his 2.x kernel, which I took and refined. But this seems to break uint3 support for my current version. Only other big difference I can think of is the use of an ulong as output buffer in my version, where your linked one still has an uint ... weird and it sucks ^^.

By the way, what have you added in 1.7.3? I downloaded and it works so far ... thanks.

Dia

I mainly intended to eliminate pyopencl as the source of the problem.

1.7.3 has a few fixes:
 - Updated phatk and poclbm to use bitselect() with BFI_INT disabled. This should help for GCN based GPUs (7970)
 - Modified WORKSIZE checking for poclbm, phatk, phatk2.
 - Disallowed -q 0 since it won't work correctly.

From what I have read bitselect() will properly compile to BFI_INT on GCN based GPUs without the crazy binary patching method required for VLIW5/VLIW4.

I'm pretty sure your change to bitselect() was not needed, because it should have worked before, too Wink. I was the one who wrote it that way.
But thanks for your hard work and the exchange we have, it's fun!

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Enigma81
Full Member
***
Offline Offline

Activity: 180
Merit: 100



View Profile
January 13, 2012, 02:13:12 AM
 #1056

Nice Upgrade.. Excellent Work..

I finally took the time to upgrade from 1.6.2 to 1.7.3..  Nice results..

Just for example, my test rig has a single 5850 and went from 398 -> 438 MH/s.  10% !!

Enigma

Diapolo
Hero Member
*****
Offline Offline

Activity: 769
Merit: 500



View Profile WWW
January 13, 2012, 07:41:00 AM
Last edit: January 13, 2012, 09:37:01 AM by Diapolo
 #1057

@jedi95: I saw that you are using PyOpenCL version 2011.1beta3 and tried to replace cl.enqueue_read_buffer(self.commandQueue, self.output_buf, self.output) with cl.enqueue_copy(self.commandQueue, self.output_buf, self.output), because enqueue_read_buffer() and enqueue_write_buffer() are not supported anymore, at least pyOpenCL docs say "Add pyopencl.enqueue_copy(). Deprecate all other transfer functions.". Perhaps a switch to the latest PyOpenCL version can fix this + we could throw out the unsupported commands. What do you think?

I read that Vector types were added aswell, see: http://documen.tician.de/pyopencl/array.html#pyopencl.array.vec

Edit: I saw a few Reject reason: stale errors, what does this error mean?

Thanks,
Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
January 13, 2012, 08:51:12 PM
 #1058

@jedi95: I saw that you are using PyOpenCL version 2011.1beta3 and tried to replace cl.enqueue_read_buffer(self.commandQueue, self.output_buf, self.output) with cl.enqueue_copy(self.commandQueue, self.output_buf, self.output), because enqueue_read_buffer() and enqueue_write_buffer() are not supported anymore, at least pyOpenCL docs say "Add pyopencl.enqueue_copy(). Deprecate all other transfer functions.". Perhaps a switch to the latest PyOpenCL version can fix this + we could throw out the unsupported commands. What do you think?

I read that Vector types were added aswell, see: http://documen.tician.de/pyopencl/array.html#pyopencl.array.vec

Edit: I saw a few Reject reason: stale errors, what does this error mean?

Thanks,
Dia

"Reject reason:" is sent by the pool server to indicate why a share was rejected. "stale" simply indicates that the share was from the previous block, and not useful.

The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.

The deprecated functions are only at the API level. enqueue_copy() uses enqueue_write_buffer() and enqueue_read_buffer() internally.

If you want to make the deprecation warnings go away, just do this: (Will not work with compiled binaries, since they use 0.92)
Code:
Replace:
 cl.enqueue_read_buffer(self.commandQueue, self.output_buf, self.output)
With:
 cl.enqueue_copy(self.commandQueue, self.output, self.output_buf)

and

Replace:
 cl.enqueue_write_buffer(self.commandQueue, self.output_buf, self.output)
With:
 cl.enqueue_copy(self.commandQueue, self.output_buf, self.output)

If you want to compare versions for yourself, you can download them here: (These only work with Python 2.6)
http://jedi95.com/files/pyopencl-0.92.zip
http://jedi95.com/files/pyopencl-2011.1.zip
http://jedi95.com/files/pyopencl-2011.2.zip

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
deepceleron
Legendary
*
Offline Offline

Activity: 1512
Merit: 1025



View Profile WWW
January 13, 2012, 09:01:36 PM
 #1059

The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.
When running Dia's kernel on the 1.7.3 Win32 exe, it spits out this message:
[13/01/2012 12:58:20] using PyOpenCL version 2011.1beta3


thanks to these lines in __init__.py:
# output used pyOpenCL version
self.interface.debug('using PyOpenCL version ' + cl.VERSION_TEXT)


The hashrate loss in 2011.x is similar to what I've seen running from source, so if 1.7.3 exe has 2011.1, maybe a repackaging can get a bit more hashrate(?)
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
January 13, 2012, 09:23:52 PM
 #1060

The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.
When running Dia's kernel on the 1.7.3 Win32 exe, it spits out this message:
[13/01/2012 12:58:20] using PyOpenCL version 2011.1beta3


thanks to these lines in __init__.py:
# output used pyOpenCL version
self.interface.debug('using PyOpenCL version ' + cl.VERSION_TEXT)


The hashrate loss in 2011.x is similar to what I've seen running from source, so if 1.7.3 exe has 2011.1, maybe a repackaging can get a bit more hashrate(?)


Ah, I must have missed some of the files when I was messing around with it trying to fix the delay getting work. The _cl.pyd file is from 0.92.

I have re-uploaded 1.7.3 with this fix applied. The old version of 1.7.3 has been re-uploaded as phoenix-1.7.3_old.zip.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
Pages: « 1 ... 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 [53] 54 55 56 57 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!