Hi!

I think I've found something that resembles a memory leak in phoenix-1.48.

I know it's not the most recent version of phoenix, but it's the one I have cooked now - people on forum seem to be complaining about it:

http://forum.bitcoin.org/index.php?topic=6458.600

So, the leak seems to be affected by the choice of the pool - which means it's unlikely something to do with the AMD SDK version (11.4 here).

Code:

root@node02:~# ps aux | grep phoenix                                                                                                                                                                               
root       368  0.6 13.6 411212 138972 pts/7   Ssl+ Jul02  12:53 /usr/bin/python ./phoenix.py -v -u http://qdot_nodeB3:supersecret@btcguild.com:8332/ -v -k phatk DEVICE=2 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32556  0.3  7.3 355028 74920 pts/4    Ssl+ Jul02   7:22 /usr/bin/python ./phoenix.py -v -u http://qdot.node2_1:supersecret@api.bitcoin.cz:8332/ -v -k phatk DEVICE=0 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32628  0.4  7.4 354804 76144 pts/5    Ssl+ Jul02   9:27 /usr/bin/python ./phoenix.py -v -u http://qdot.node2_2:supersecret@api.bitcoin.cz:8332/ -v -k phatk DEVICE=1 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32661  0.4  7.4 354804 75744 pts/6    Ssl+ Jul02   9:55 /usr/bin/python ./phoenix.py -v -u http://qdot.node2_3:supersecret@api.bitcoin.cz:8332/ -v -k phatk DEVICE=2 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32703  0.4 12.0 419708 123136 pts/9   Ssl+ Jul02   9:30 /usr/bin/python ./phoenix.py -v -u http://qdot_nodeB1:supersecret@btcguild.com:8332/ -v -k phatk DEVICE=0 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32752  0.6 13.4 424524 137260 pts/8   Ssl+ Jul02  12:31 /usr/bin/python ./phoenix.py -v -u http://qdot_nodeB2:supersecret@btcguild.com:8332/ -v -k phatk DEVICE=1 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128

As you can see, it only leeks on btcguild - for some reason slush's pool keeps the miners immune from this issue.. any differences between the two?

Hi!

I wonder if there is (it's so simple I must not be the first user to come up with it) a patch for any OpenCL mining software that enables switching to other pools in a round-robin fashion in the event pool becomes unreachable.


Incentives for miners:
 * Register at multiple pools, mine even when a pool is down
 * Stop worrying about down pools
 * 'Steady as she goes' thermal workload on mining rigs.. I wonder if cooling down the idle miner and reheating it, negatively impacts it's reliability.. it probably does.

Incentives for network:
 * No tragic loss of 40% hashing power should deepbit.net go down again.. which means no confirmations for 30mins etc..
 * Overall balanced use of pools - entering multiple pools, each of which dying randomly means the miners would distribute evenly on all pools entered in the client

Disincentives for miners:
 * Having to manage payouts from multiple pools.. not quite as important, since most pay automatically after certain threshold.
 * Hard to estimate earnings.

Hi!

Am I the only one concerned by the fact, that deepbit.net's contributors provide nearly 35% of network's hashing power?

By the very definition of pooling, the control server has all it needs to direct all it's peers to hash nearly anything, with no decentralized checks and balances to ensure the block chain it is directing it's computing capability in in fact an undoctored bitcoin broadcast.