It should work fine on Ubuntu. Use latest fglrx (ATI's proprietary driver) and stream 2.1
|
|
|
Use stream 2.1 or 2.2. Not sure why, but 2.3 is slower.
|
|
|
Ok, just confirmed... latest version is good only with 'difficulty = 1'. Working properly only on slush's pool.
Please revert to previous version for mining solo. I'm working on a fix.
|
|
|
At least anyone saying bitcoin is not anonymous enough can try to prove it.
|
|
|
Updated to use ArtForz kernel. Lowered default 'frames' to 30.
I am seeing biggest improvement on linux, Stream 2.1, 2x5970 - ~5%
Thanks ArtForz, tcatm
|
|
|
I made some pool related changes - socket timeout is now 5 seconds to avoid solving some jobs more than once. Exception handling should be somewhat better too.
|
|
|
You are right. --- But, consider this:
1. The miner is general purpose. It have to work with the official bincoin client.
Searching for more than one solution doesn't break compatibility - bitcoind would just reject second solution. Nothing is lost, you will have new search space in a short period. But even if other miners do this, I am not quite sure if it improves apparent performance (to pool). Every nonce has equal probability.
|
|
|
Hash accepted means only that the block was accepted by your client as a valid solution. Next, it's broadcast to your peers, they broadcast it to theirs and so on. For some reason this broadcast didn't reach my node. This means it didn't reach other parts of the network too. Does someone see this particular hash in debug.log?
I definitely recommend opening your port 8333 to ensure better connectivity. This would also make someone cornering you out of the network harder. (I am not saying someone cornered you actually, it's difficult even with the port closed).
As for the pool - don't mix up problems. There was a major change recently and you should update poclbm to latest version.
|
|
|
Fixed issue with intermittent solving for duplicate pool job. Anyone using the miner against a pool should upgrade to latest version to avoid losing shares.
Also, kernel now compiles with vectors on Stream 2.1
|
|
|
A solved block will then be around (1kb * 2000tps * 60 * 10) / 1024 / 1024 = 1.14 gigabytes per block.
Would someone please explain why sending solved block with raw TXs is needed? Isn't it possible to broadcast lighter version of solved block with only TX hashes (32 bytes each), bringing above number to ~32 megabytes (instead of a GB)?
|
|
|
Just posted my best settings for Windows 7, Stream 2.2, AMD 5770, 5870 (first post). Teknohog, could you please try with Stream 2.1. I can't see why 'vectors' would give invalid results.
|
|
|
FairUser, please describe your setup with as many details as possible. When did it start showing this?
Does anyone else see something similar?
|
|
|
Updated to support latest change of slush's pool which now returns JSON RPC error when its back-end server is down. Original bitcoind never returns such error as a response to getwork(data).
Summarized, this should help miner continue after pool downtime.
|
|
|
Elanthius, in previous version I forgot to remove OpenCL.dll from the py2exe distribution. It is not there in current version and you should check that you have Stream SDK 2.2 installed and proper version of OpenCL.dll loadable by miner. Be sure there aren't multiple versions - for example if an nvidia one from previous drivers load first it could give you this error.
|
|
|
Just wanted to announce here that my miner now has some fixes related to pool usage. It should cycle over network problems. Also, mining is done in a separate thread to avoid performance drops due to IO.
|
|
|
Moved actual search to separate thread to avoid IO overhead. It wasn't a problem when used with local bitcoin client, but become a problem with slush's mining pool.
Davout, check if crossfire is switched off. Or try with lower clock. Xelister reported on #bitcoin-dev similar issues with 5970 and Diablo's miner.
|
|
|
16/12/2010 20:xx. xxxxxxxx, invalid or stale Exactly what you will get with 'normal' mining - pool server received new, network block just before your last solution. Because pool target is quite low you will see this more often. With ask rate of 5 seconds and network speed of 6 blocks/hour there is probability of 1/120 'shares' to see this.
|
|
|
Added update of block time every second and support for targets < 32 bits. Output now shows block hash and acceptance status.
|
|
|
From bitcoin docs # By default, only RPC connections from localhost are allowed. Specify # as many rpcallowip= settings as you like to allow connections from # other hosts (and you may use * as a wildcard character): #rpcallowip=10.1.1.34 #rpcallowip=192.168.1.*
|
|
|
|