Phoenix - Efficient, fast, modular miner

[Mato Kira]

I'm running a 9800M GTS, only getting about 14.8Mh/s with AGGRESSION=3 and WORKSIZE=64. Anyone have any suggestions for upping this?

[1715294037]

1715294037

[5tr1k3r]

I'm running a 9800M GTS, only getting about 14.8Mh/s with AGGRESSION=3 and WORKSIZE=64. Anyone have any suggestions for upping this?

Unfortunately, there is only one suggestion — buy a decent amd card, and preferably not a mobile one. https://en.bitcoin.it/wiki/Mining_hardware_comparison

[memvola]

I've been playing around with Pushpool (software to run a mining pool) in combination with Phoenix, and found that the default Phoenix settings may cause some unnecessary rejected shares for slow miners on a Pushpool server that offers Long Polling. Since several Pushpool-based mining pools have recently come into existence this probably affects some users already.

...

The immediate solution is to use Phoenix's undocumented lpaskrate command line parameter, which is the Long Poll equivalent of the askrate parameter. A more structural fix would be for the Phoenix client to change lpaskrate default value from 0 to something sensible in the range 10-119. Of course the expiry policy may also be changed by the pool operator. But the default Pushpool work expiry policy is not overly strict in my opinion; work that's over 2 minutes old misses out on a lot of recent transactions and therefore on the transaction fees these include.

Thanks for the hint. I've been getting a very high rejected rate (50%-75%) on slower miners using phoenix. Doesn't happen while using poclbm for instance...

Looks like lpaskrate was introduced in 1.48, but it didn't solve my problems. Options I use are roughly:

Code:

./phoenix.py AGGRESSION=9 WORKSIZE=256 -u http://1XXX0pps:x@continuumpool.com:8332/;lpaskrate=20 DEVICE=0

The same with swepool. I tried reducing askrate to 5 as well. Any ideas why this didn't work?

[Mato Kira]

I'm running a 9800M GTS, only getting about 14.8Mh/s with AGGRESSION=3 and WORKSIZE=64. Anyone have any suggestions for upping this?

Unfortunately, there is only one suggestion — buy a decent amd card, and preferably not a mobile one. https://en.bitcoin.it/wiki/Mining_hardware_comparison

Kinda locked into a solution with it being a laptop and all.. are there any effective ways to overclock?

[asdfg]

Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
  File "Miner.pyc", line 75, in start
  File "phoenix.py", line 111, in makeKernel
  File "kernels\poclbm\__init__.py", line 22, in <module>
    import pyopencl as cl
  File "zipextimporter.pyc", line 82, in load_module
  File "pyopencl\__init__.pyc", line 3, in <module>
  File "zipextimporter.pyc", line 98, in load_module
ImportError: MemoryLoadLibrary failed loading pyopencl\_cl.pyd


 

[Etheric]

Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
  File "Miner.pyc", line 75, in start
  File "phoenix.py", line 111, in makeKernel
  File "kernels\poclbm\__init__.py", line 22, in <module>
    import pyopencl as cl
  File "zipextimporter.pyc", line 82, in load_module
  File "pyopencl\__init__.pyc", line 3, in <module>
  File "zipextimporter.pyc", line 98, in load_module
ImportError: MemoryLoadLibrary failed loading pyopencl\_cl.pyd


 

I had this problem too initially. I think it is related to the SDK driver not being properly installed.

I fixed it by uninstalling my current drivers, booting into safe mode, and using Driver Sweeper to remove all traces of old drivers and then installing the full 11.5 Catalyst suite.

Hope that helps you too!

[asdfg]

Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
  File "Miner.pyc", line 75, in start
  File "phoenix.py", line 111, in makeKernel
  File "kernels\poclbm\__init__.py", line 22, in <module>
    import pyopencl as cl
  File "zipextimporter.pyc", line 82, in load_module
  File "pyopencl\__init__.pyc", line 3, in <module>
  File "zipextimporter.pyc", line 98, in load_module
ImportError: MemoryLoadLibrary failed loading pyopencl\_cl.pyd


 

I had this problem too initially. I think it is related to the SDK driver not being properly installed.

I fixed it by uninstalling my current drivers, booting into safe mode, and using Driver Sweeper to remove all traces of old drivers and then installing the full 11.5 Catalyst suite.

Hope that helps you too!

Updated my drivers and it works, thank you.

[CubedRoot]

CAn someone tell my why a LP push like the ones below locks my GPU down, and forces me to restart?

I am using Ubuntu 64, newest phoenix and phatk kernel

Code:

[11/06/2011 14:42:10] Result: ac8fb0cd accepted
[11/06/2011 14:42:18] Result: a42fd6a2 accepted
[11/06/2011 14:42:35] Result: 652fb629 accepted
[11/06/2011 14:49:17] LP: New work pushed
[11/06/2011 14:52:32] LP: New work pushed
[11/06/2011 14:56:03] LP: New work pushed
[11/06/2011 14:57:19] LP: New work pushed
[309.70 Mhash/sec] [10 Accepted] [0 Rejected] [RPC (+LP)]

[MintCondition]

The immediate solution is to use Phoenix's undocumented lpaskrate command line parameter, which is the Long Poll equivalent of the askrate parameter. A more structural fix would be for the Phoenix client to change lpaskrate default value from 0 to something sensible in the range 10-119. Of course the expiry policy may also be changed by the pool operator. But the default Pushpool work expiry policy is not overly strict in my opinion; work that's over 2 minutes old misses out on a lot of recent transactions and therefore on the transaction fees these include.

An update on this bug: Upon further research into the Phoenix code it seems that specifying the lpaskrate argument does not actually solve anything, so please ignore the quoted solution. I originally assumed the queuesize was intended as both preferred and maximum size, so that the oldest work would be abandoned when overfilling the queue. Instead, current work will only be abandoned when a new block has been detected; any forced getwork responses will just be added to the workqueue, only making the problem worse.

A better avenue for improvement, although more involved, might be to add an expiration mechanism to the Phoenix code. Until then I'd recommend never mining at less than 36MH/s to avoid rejected shares caused by this bug.

[jondecker76]

For a little bit while deepbit was down today, I decided to try solo mining...  DUring the short period that I tried it (About 10 minutes),  phoenix kept reporting "Result didn't meet full difficulty, not sending"

what does this mean?  I was showing a normal hash rate, and showing 0 accepter, 0 rejected.  I've never seen this before mining in any pool.

thanks!

[jedi95]

The immediate solution is to use Phoenix's undocumented lpaskrate command line parameter, which is the Long Poll equivalent of the askrate parameter. A more structural fix would be for the Phoenix client to change lpaskrate default value from 0 to something sensible in the range 10-119. Of course the expiry policy may also be changed by the pool operator. But the default Pushpool work expiry policy is not overly strict in my opinion; work that's over 2 minutes old misses out on a lot of recent transactions and therefore on the transaction fees these include.

An update on this bug: Upon further research into the Phoenix code it seems that specifying the lpaskrate argument does not actually solve anything, so please ignore the quoted solution. I originally assumed the queuesize was intended as both preferred and maximum size, so that the oldest work would be abandoned when overfilling the queue. Instead, current work will only be abandoned when a new block has been detected; any forced getwork responses will just be added to the workqueue, only making the problem worse.

A better avenue for improvement, although more involved, might be to add an expiration mechanism to the Phoenix code. Until then I'd recommend never mining at less than 36MH/s to avoid rejected shares caused by this bug.

This is not accurate concerning the queue. The queue itself uses the deque class which has a maximum size set to the size the user specifies. Adding additional work to queue will automatically purge the oldest work if the queue is full. See the documentation for deque here:

If maxlen is not specified or is None, deques may grow to an arbitrary length. Otherwise, the deque is bounded to the specified maximum length. Once a bounded length deque is full, when new items are added, a corresponding number of items are discarded from the opposite end. Bounded length deques provide functionality similar to the tail filter in Unix. They are also useful for tracking transactions and other pools of data where only the most recent activity is of interest.

http://docs.python.org/library/collections.html#collections.deque

[finnthecelt]

I'm running a 9800M GTS, only getting about 14.8Mh/s with AGGRESSION=3 and WORKSIZE=64. Anyone have any suggestions for upping this?

Unfortunately, there is only one suggestion — buy a decent amd card, and preferably not a mobile one. https://en.bitcoin.it/wiki/Mining_hardware_comparison

Kinda locked into a solution with it being a laptop and all.. are there any effective ways to overclock?

http://www.overclock.net/nvidia-drivers-overclocking-software/461651-9800m-gts-overclocking-possible.html

[Mousepotato]

I just downclocked my memory to 300MHz (down from 1200MHz) and I picked up a good 22-23Mh/s.  Sweet!

[SchizophrenicX]

Would you guys recommend LinuxCoin?

I have been trying to get my Ubuntu up but to no avail. LiveCD installs on 4 GB drives but I think a full install requires > 4.4 GB

[AngstHase]

any chance to get a phoenix update soon?

[supa]

I tried to skim through the thread but I still have a couple of questions regarding the kernel AGGRESSION parameter and -a (average samples).

For starters...  In Windows, if I set my aggression higher than 15, it seems the whole thing explodes.  15 works OK with a laggy display (expected).

In Linux, I don't care about the display, so I put my aggression to 20.  Linux gets a higher hash rate.  I'm not sure anything over 15 actually does anything, but 20 seemed like a good number at the time....

What is this doing... ?

Is there a relation to this and the -f (frames) in poclbm?  A windows machine with poclbm -f 0 is still mostly usable.

Finally, according to this -

-a (average samples) - Sets the number of samples to use for hashrate averaging. Default is 10. You might want to lower this for longer kernel execution times. (high aggression)

I should make a lower -a for higher aggression.  I tried setting it to "-a 1" without much difference and even "-a 0".  What does this do?

Using phatk kernel if it matters.

[jedi95]

AGGRESSION is used to set the number of nonces to run per kernel execution. Values above 16 won't do anything because nonces to run = 2^(16 + AGGRESSION) Setting a higher value for AGGRESSION will simply round down to the highest valid value (16)

The -a parameter is used for the hashrate display. With higher aggression settings kernels can take several seconds to run, so this makes taking 16 samples rather pointless. The reason multiple samples are used is that otherwise the displayed hashrate would fluctuate greatly at low aggression.

The -f option in poclbm is somewhat similar to aggression because it also controls kernel execution sizes. The main difference is that aggression sets the number of nonces to run per execution while -f sets the target time for each execution. (-f adjusts the number of nonces constantly to maintain the target execution time)

As for updates to Phoenix, I think I have a solid workaround for the idle problem now. I still don't know the exact reason for it, but the workaround should be sufficient to recover automatically. I will release this is 1.50 shortly if I don't find any issues in testing. These changes are included in the latest SVN revision (r101) if anyone wants to try it.

[SchizophrenicX]

constantly getting failed to connect: retrying message on Ubuntu 11.04. Followed the guide around here.
poclbm connects normally. so I'm guessing I'm missing something...

[finnthecelt]

constantly getting failed to connect: retrying message on Ubuntu 11.04. Followed the guide around here.
poclbm connects normally. so I'm guessing I'm missing something...

Yeah, windows.

[SchizophrenicX]

yea. I'm having windows trouble right now and I have been trying to get my miners running on linux since it's free. I don't even have a working windows machine right now unfortunately... although at this moment it seems like one of my old XP machine is able to restore it's OS from a recovery partition.

Anyway... Here is what shows in terminal

Code:

me@ubuntu:~/poclbm$ ./poclbm.py
No device specified or device not found, use -d to specify one of the following

[0]	AMD Phenom(tm) II X4 B55 Processor
[1]	Cypress
[2]	Cypress
[3]	Cypress
[4]	Cypress
[5]	Cypress
me@ubuntu:~/poclbm$ cd ../phoenix
me@ubuntu:~/phoenix$ ./phoenix.py -u http://username.workername:workerpassword@api.bitcoin.cz -k phatk DEVICE=1 VECTORS BFI_INT WORKSIZE=256 AGGRESSION=7
[15/06/2011 01:47:29] Phoenix r101 starting...
[15/06/2011 01:47:30] Failed to connect, retrying...
[15/06/2011 01:47:45] Failed to connect, retrying...
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]^Cme@ubuntu:~/phoenix$ cd ../poclbm
wenbin@Binbuntu:~/poclbm$ ./poclbm.py -d1 -o api.bitcoin.cz -u username.workername --pass=workerpassword -v -w256 -f30
15/06/2011 01:48:39, 0b7c45c9, accepted                     
15/06/2011 01:48:44, f2c5f913, accepted                     
299841 khash/s