Bitcoin Forum
October 31, 2024, 11:45:31 AM *
News: Bitcoin Pumpkin Carving Contest
 
   Home   Help Search Login Register More  
Pages: « 1 2 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 760748 times)
Mato Kira
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
June 10, 2011, 11:58:27 PM
 #681

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?
5tr1k3r
Newbie
*
Offline Offline

Activity: 39
Merit: 0


View Profile
June 11, 2011, 12:36:35 AM
 #682

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

Activity: 938
Merit: 1002


View Profile
June 11, 2011, 12:43:50 AM
 #683

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

Activity: 2
Merit: 0


View Profile
June 11, 2011, 01:33:59 AM
 #684

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

Activity: 2
Merit: 0


View Profile
June 11, 2011, 04:20:34 PM
 #685

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


 Huh
Etheric
Newbie
*
Offline Offline

Activity: 46
Merit: 0


View Profile
June 11, 2011, 05:56:10 PM
 #686

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


 Huh

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

Activity: 2
Merit: 0


View Profile
June 11, 2011, 06:43:51 PM
 #687

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


 Huh

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

Activity: 291
Merit: 250


View Profile
June 11, 2011, 07:05:08 PM
 #688

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

Activity: 1147
Merit: 1007



View Profile
June 11, 2011, 07:33:57 PM
 #689


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

Activity: 238
Merit: 100


View Profile
June 11, 2011, 09:34:07 PM
 #690

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!

RollerBot Advanced Trading Platform
https://bitcointalk.org/index.php?topic=447727.0
BTC Donations for development: 1H36oTJsi3adFh68wwzz95tPP2xoAoTmhC
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
June 12, 2011, 06:23:44 PM
 #691


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:

Quote
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


Phoenix Miner developer

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

Activity: 140
Merit: 101


View Profile
June 12, 2011, 07:02:39 PM
 #692

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

Activity: 896
Merit: 1000


Seal Cub Clubbing Club


View Profile
June 12, 2011, 08:46:39 PM
 #693

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

Mousepotato
SchizophrenicX
Member
**
Offline Offline

Activity: 112
Merit: 100

"I'm not psychic; I'm just damn good"


View Profile
June 13, 2011, 11:37:53 AM
 #694

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

Activity: 39
Merit: 0


View Profile
June 13, 2011, 12:33:27 PM
 #695

any chance to get a phoenix update soon?
supa
Copper Member
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
June 13, 2011, 03:07:35 PM
 #696


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

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 -
Quote
-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 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
June 13, 2011, 08:25:01 PM
 #697

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.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
SchizophrenicX
Member
**
Offline Offline

Activity: 112
Merit: 100

"I'm not psychic; I'm just damn good"


View Profile
June 14, 2011, 01:59:10 PM
 #698

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

Activity: 140
Merit: 101


View Profile
June 14, 2011, 05:35:20 PM
 #699

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

Activity: 112
Merit: 100

"I'm not psychic; I'm just damn good"


View Profile
June 14, 2011, 06:08:37 PM
 #700

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

Pages: « 1 2 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!