 Show Posts
|
|
Pages: [1]
|
|
1
|
Bitcoin / Mining software (miners) / Re: Phoenix Miner - memory leak (pool dependent)
|
on: July 04, 2011, 04:43:29 AM
|
I use BTCGuild exclusively, and have been having the problem that when a fresh phoenix is started, the GPU usage is a straight 99% line, but over several days it turns into a sine wave from 90% - 99% , which means the GPU's are not being fully used.
Could this be related?
It could be either that or the GPU overheating and running some form of load reduction. I've seen both effects. You can most easily test it by switching to a different pool, or by monitoring the GPU temperature and clocks. Basically, when the GPU overheats, it clocks down. On the other hand, mining on a machine with some swap memory (paging file) could cause the same effect due to leaks - on my miners it just gets the system to kill the leaking worker, with no leak related slowdown - but that's because my miners have very little RAM, and no swap memory. |
|
|
|
|
2
|
Bitcoin / Mining software (miners) / Phoenix Miner - memory leak (pool dependent)
|
on: July 03, 2011, 08:34:28 PM
|
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.600So, 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). 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? |
|
|
|
|
3
|
Other / Beginners & Help / Re: Voltage Control of HD5850 in Ubuntu?
|
on: July 01, 2011, 05:27:18 PM
|
Don't you need to run xhost + from an xterm before you can just connect to the X11 session?
xhost + applies if you have to use a connection that's missing the MIT-MAGIC-COOKIE - if you're using the same user that the X11 server runs from, the cookies should be sufficient and tasty. |
|
|
|
|
4
|
Other / Beginners & Help / Re: Whitelist Requests (Want out of here?)
|
on: July 01, 2011, 05:20:09 PM
|
I just want to be able to post again.. the way I've been able when I joined a while ago  A software engineer from Poland, mining, investing, heck, everyday having a bitcoin related discussion at Warsaw hackerspace. |
|
|
|
|
6
|
Other / Beginners & Help / Re: Voltage Control of HD5850 in Ubuntu?
|
on: June 24, 2011, 10:36:32 AM
|
|
And in terms of accessing via SSH:
Install 'screen' - not strictly necessary, but useful in keeping a program running while you logout from shell
run 'screen'
run 'startx' - this startx an X Server on the machine
in a separate screen window ('Ctrl-a c') run:
export DISPLAY=:0
'your-miner-command-line'
|
|
|
|
|
7
|
Bitcoin / Mining / Re: Mining with multiple pools (round robin)
|
on: June 03, 2011, 10:06:03 AM
|
Disincentives for pool operators and the network:
* If someone manages to DDoS two or three pools, the other ones will be taken down by the load of additional miners switching over to them as well?
A sensible pool should be able to handle growth in legitimate traffic. Speaking with no experience in bitcoin pool operations in general, but with a lot of experience in designing scalable web applications, a typical DDoS is roughly 10x larger than a foreseeable legitimate traffic. I don't think all legitimate miners could bring down a pool that is supposed to have a fighting chance against organized DDoS. |
|
|
|
|
8
|
Bitcoin / Mining / Re: Mining with multiple pools (round robin)
|
on: June 03, 2011, 10:01:47 AM
|
I just run 2 miners on each GPU. They work at 50% to each pool and if one pool goes down the second pool's miner ramps up to 100%. I seem to get a higher total hash rate doing this than with a single pool as well.
That's a good hint! Mining is ALU-bound, so it should behave that way Unfortunately, on my machine, it (sometimes??) crashes the other miner? Perhaps it's just X11 that got in the way, I disabled it, and it should be chugging along just fine. |
|
|
|
|
9
|
Bitcoin / Mining / Mining with multiple pools (round robin)
|
on: June 03, 2011, 09:46:17 AM
|
|
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.
|
|
|
|
|
10
|
Bitcoin / Development & Technical Discussion / Re: The 50% total hashing power - pooling flaw?
|
on: June 02, 2011, 09:14:52 PM
|
|
Perhaps it's time to add another desired feature to the pooling software?
I believe it should be possible to design the software in such a way, that is to separate the 'shares of work' assignment/reporting (to the pooling server), and the 'block-chain' fetching (which ought to be performed through decentralized means).
Can it? I don't see a reason why not..
I'm not concerned about deepbit.net having a malicious intent, but we should safeguard against, say, domain takeover, server bugs etc?
|
|
|
|
|
11
|
Bitcoin / Development & Technical Discussion / The 50% total hashing power - pooling flaw?
|
on: June 02, 2011, 08:41:29 PM
|
|
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.
|
|
|
|
|
