All nonce is checked in ~7 seconds on 5870 GPU.
It's actually 12 seconds or more, but I update at whatever_nonce_exhaust_time - TIMEOUT(=5 seconds). Line 114 - 115 of BitcoinMiner.py self.askrate = max(int(askrate), 1)
self.askrate = min(self.askrate, 10) Yes, we're sure. If you use more than 10 seconds for the askrate, it will force a maximum of 10 seconds. There is a separate independent update mechanism since LP was introduced. 'self.askrate' takes place only when LP is off. Guys, I really respect your hard work providing another pool. But please cut all this 'efficiency' pseudo-science. There is no correlation between searching whole 'nonce space' and the results you find. Yes, it affects server load, but there are other methods to solve this. |
|
|
|
|
This warning appears here with PyOpenCL built with NumPy 1.5.1.
No warnings if using NumPy 1.4.1. I'll try to fix this in poclbm.
|
|
|
|
... I set my timeout to 15 ...
What are your command line options? How do you set the timeout? |
|
|
|
|
Please give some more details about your OS, driver version, ATI Stream (APP) SDK version... Do you have crossfire?
|
|
|
|
|
It shouldn't use any CPU (unless you use it on your CPU which you should not). Any other CPU usage is cleanly problem of driver + OpenCL SDK + OS.
|
|
|
|
|
Perhaps really really low priority, but I want to remind you about redundant transmission of transactions with each block. May be it's better to solve this sooner rather than later.
My proposal is to modify 'block' message to contain only transaction hashes. After that, 'getdata' can be used to further acquire missing transactions from block's sender.
Unfortunately I don't see how this can be done without breaking current protocol.
|
|
|
|
The "Invalid or Stale" rejection message should be split out into two error messages if possible,
That way miner side can trouble shoot when receiving a lot of these errors. If it is string of stale then it maybe a comms. problem on miner side (or pool connection possibly down).
Computation is checked on CPU and you will see a 'verification failed' message. 'Invalid or stale' is received whenever the server rejected your result. It now is almost 100% 'stale' than 'invalid', but I didn't change the message because it would have caused more questions. ...every time I want to play a movie or youtube(flash player), my computer will hang up! This is problem with flash itself, if not hanging it at least 'reserves' roughly half of GPU for itself. |
|
|
|
Now 2 things strike me as odd:
1.) targetH is passed as 0xffff0000 (BitcoinMiner.py around line 293). why not 0? doesn't H have to be 0 even for a difficulty 1 block?
2.) (parts) of the calculation of G is commented out in the kernel code (likely to save some cycles, assuming that G is not going to be needed)...
...but G is used in the solution condition. So since G is some intermediary value of sha256 and targetG is 0, why does this even work?
1.) Excuse me for this mildly obfuscated code. target[0] and [1] are actually A and B of original target - I'm using them just to pass a made up 32 bit target. If you look at kernel parameters you'll see that target[0] (0xFFFF0000) is passed as G. 2.) G is used in belowOrEquals because I didn't managed to understand why this leads to better/faster assembler  I left it there wondering when someone will ask this question. |
|
|
|
|
Just fixed it to avoid this specific problem on Macs.
|
|
|
|
|
My humble opinion - there is no free lunch. Every transaction must have a price. This price should be a constant, bound to current definitions of COIN and CENT.
Anything else is just a dream.
|
|
|
|
|
Client should also warn about low priority transactions and suggest a fee to increase chance for inclusion.
|
|
|
|
"Difficulty 1 hashes" are hashes that nearly solved the block...
Just to clarify - these would be winning hashes if difficulty is 1. Exactly equivalent to slush's pool shares. |
|
|
|
Great job Kiv, really glad to see this. I would definitely donate |
|
|
|
|
I just uploaded latest version, could you please update and try again?
|
|
|
|
|
New version is up. Changes:
- handling httplib exceptions
- proper handling of wrong user name and password when mining with bitcoind
- support for more than one OpenCL platform
- caching kernel binaries for faster startup
- always flush stdout
|
|
|
|
aistto, see http://blog.zorinaq.com/?e=11Initially, you can start the miner on first device, then connect your monitor to second device to make it available. If this seems too difficult, see above link for a way to keep second device always active. This is a windows only problem. |
|
|
|
|
nster, check if you have proper OpenCL support. Remove any previous VGA drivers. Most probably you switched from Nvidia to AMD and there are conflicting versions of OpenCL.dll on you machine.
|
|
|
|
@aistto Switch crossfire off for now. Until I found why versions until and including 20101126 work with crossfire and later ones don't. Using python 3.2 on windows  No, no, no... use python 2.6 poclbm is not compatible with python 3. Actually python 2 and python 3 are quite different and not compatible with each other. |
|
|
|
I really can't hide my disappointment waited hours for Hal to provide the correct key - and to see that someone got it 3 blocks earlier. Should master my 'F5' key. There is a rather old patch (SVN 195) at https://github.com/m0mchil/bitcoin-impex-keys which supports RPC initiated exporting and importing of keys in PEM format. It also exports corresponding block numbers to speed up import. The reason I didn't announce it back then is that it doesn't solve the double spend problem. The patch could be easily modified to not remove exported key from wallet (it does so at the moment) allowing copying of keys. If anyone's interested I can easily add import method using just private key. |
|
|
|
|
Show Posts
