 Show Posts
|
|
Pages: [1]
|
|
Hi,
Would it be possible to offer a direct link to multibit-exe.jar for downloding? I am running multibit from an encrypted volume and this would simplify my update process significantly. Now I have to run the installer every time in a virtual machine.
Thanks
|
|
|
|
|
rNtgpmmwf2xLgHNPpgQmGgy9DsYegvtNPo
|
|
|
|
|
I can confirm that the patch now works just fine. I just generated my first 50 BTC with it. And since this patch doubles the speed I think it's only fair if I donated half of that to tcatm.
|
|
|
|
|
CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp.
|
|
|
|
Here's the output on stderr: bitcoind: main.cpp:2741: void BitcoinMiner(): Assertion `("break caught by CRITICAL_BLOCK!", !fcriticalblockonce)' failed.
|
|
|
|
The test program does not fail $ ./test ../blocks.txt
SHA256 test started
70293
found solutions = 70293
total hashes = 139463136
total time = 63250 ms
average speed: 2204 khash/s
Does the test program run on a single thread? Finally, I have the same problem with both -march=amdfam10 and -march=native. The cpu is a Opteron 2374. |
|
|
|
Ok I tried again, this time with no extra patches. I just cloned your git tree and compiled it. It still crashes. Here's the stack backtrace: #0 0x00007ffff710b1b5 in raise () from /lib/libc.so.6
#1 0x00007ffff710c5e0 in abort () from /lib/libc.so.6
#2 0x00007ffff71042d1 in __assert_fail () from /lib/libc.so.6
#3 0x00000000004628de in BitcoinMiner () at main.cpp:2741
#4 0x0000000000462d70 in ThreadBitcoinMiner (parg=0x391e) at main.cpp:2518
#5 0x00007ffff6ec3894 in start_thread () from /lib/libpthread.so.0
#6 0x00007ffff71aa07d in clone () from /lib/libc.so.6
I have also uploaded here (link removed) the sources with the object files as well as the a core dump and the binary. |
|
|
|
I had 5 machines running today and when I checked back 10 hours later, 4 of them had crashed, in the same way as with the previous times (i.e. right after they had generated a new block but before they broadcasted it). I created a tarball containing the coredump, backtrace, binary and the sources I used to compile it including the compiled object files. You can get it from here (link removed). Hope that helps. EDIT: Ok, I just noticed that both your patch and the patch for the getkhps rpc (from http://www.alloscomp.com/bitcoin/) modify the function BitcoinMiner in main.cpp (which is where the segfault occurs) so this must be the reason for the seqfaults. I will try to test it without the getkhps patch. |
|
|
|
|
I modified bitcoind so that it doen't fork to the background and now I can debug it with gdb. Next time it crashes gdb will give me a backtrace.
|
|
|
|
I did segfault according to dmesg: bitcoind[2469]: segfault at 0 ip 00007fe92c5b3f32 sp 00007fff15e5f6b0 error 4 in libc-2.11.2.so[7fe92c57e000+150000]
I don't have a stack trace. |
|
|
|
|
r121 from the svn patched with the patch from the post #21 running on a Opteron/x86_64
|
|
|
|
I kept running the patched version on 2 machines and the following has happened 5 times: bitcoind crashes and debug.log contains the following: proof-of-work found
hash: 00000000001c3530e42b2c7e1a20de01436882d0c1de0b63db6be8e6194255dd
target: 00000000010c5a00000000000000000000000000000000000000000000000000
CBlock(hash=00000000001c3530, ver=1, hashPrevBlock=0000000000253ab5, hashMerkleRoot=89541f, nTime=1280867359, nBits=1c010c5a, nNonce=3915571979, vtx=2)
CTransaction(hash=4fcb8e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(000000, -1), coinbase 045a0c011c021b04)
CTxOut(nValue=50.00000000, scriptPubKey=0xCE5264238BAC29160CDC9C)
CTransaction(hash=8f2466, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(77aaae, 1), scriptSig=0x01F561A9044BF348CEF6F4)
CTxOut(nValue=5.00000000, scriptPubKey=OP_DUP OP_HASH160 0xB13A)
vMerkleTree: 4fcb8e 8f2466 89541f
08/03/10 20:29 generated 50.00
AddToWallet 4fcb8e new
AddToBlockIndex: new best=00000000001c3530 height=72112
ProcessBlock: ACCEPTED
sending: inv
I guess this means that a new block has been generated. But when I restart bitcoind the balance is still zero. When I ask for a list of generated blocks I get the following: $ ./bitcoind listgenerated
[
{
"value" : 50.00000000000000,
"maturesIn" : -1,
"accepted" : false,
"confirmations" : 0,
"genTime" : 1280867359
}
]
(listgenerated is from the patch at http://www.alloscomp.com/bitcoin/) I guess this means that my client produced a block but it crashed before it was able to broadcast it. |
|
|
|
|
I thought there were no transaction fees yet.
|
|
|
|
|
A few days ago I generated 50.01000000000000 BTC. How is this possible? It now has more than 1000 confirmations.
|
|
|
|
|
After 52 hours of trying with no blocks generated, I give up and I am switching back to the vanilla bitcoin.
The probability of getting no blocks within 52 hours at 51,000 khash/s is 0.011%. So I conclude that the patch doesn't work and I am 99.989% confident about that. I hope that tcatm provides some explanation on how to use the supplied test program.
|
|
|
|
With the patch above, I was unable to build the test program. You?
Under x86 I had to include cryptopp/obj/cpu.o in the list of object files, otherwise "make test" would fail. Under x86_64 I had no such issue. The original patch posted is working just fine for me (Opteron 2376), and did double my performance over the stock 0.3.6 client. I was even able to port its minor changes to 0.3.7 successfully, with the same results.
As I said above I did notice an imporvement in performace too, but I am not sure the patched version works correctly. Have you been able to generate any blocks with the patched version? |
|
|
|
Is it a AMD only optimization perhaps?
Or a 64-bit only optimization. |
|
|
|
I have been able to apply the patch against SVN (r121) and I tested it on 2 machines: - on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!)
- on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121)
The strange thing is that despite the fact that I have been running it on 6 Opterons (i.e. 6x4=24 cores) for 40 hours with an average rate of 51,000 khash/s, I still haven't generated any blocks. The probability of this (no blocks, 40 hours, 51,000 khash/s and diffuculty=244.2) is 0.09% or 1/1098. Are you sure this thing works correctly and that the reported rate is correct? How do I run the included test program? |
|
|
|
|
