Pages:
Author

Topic: 4 hashes parallel on SSE2 CPUs for 0.3.6 - page 2. (Read 21996 times)

full member
Activity: 307
Merit: 102
August 08, 2010, 02:37:13 AM
#68
I just tried again with the latest version from your github. I'm still seeing a drop in performance compared to the vanilla source.

My system went from ~7100 to ~4200.

This particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz.
sr. member
Activity: 337
Merit: 263
August 07, 2010, 06:59:55 PM
#67
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.
That's nice to hear. Thanks for the donation and thanks to everyone else who donated!
newbie
Activity: 18
Merit: 0
August 07, 2010, 06:51:07 PM
#66
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.
founder
Activity: 364
Merit: 6472
August 07, 2010, 05:16:01 PM
#65
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.
Sorry about that.  CRITICAL_BLOCK isn't perfect.  You have to be careful not to break or continue out of it.  There's an assert that catches and warns about break.  I can be criticized for using it, but the syntax would be so much more bloated and error prone without it.

Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around?  For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow?  I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level.  I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope.  But it would be really nice if this was working on most CPUs.
sr. member
Activity: 337
Merit: 263
August 06, 2010, 07:54:04 AM
#64
Thanks! That got probably mixed up when I patched the file with an older diff. I fixed the git: http://github.com/tcatm/bitcoin-cruncher
newbie
Activity: 18
Merit: 0
August 06, 2010, 07:37:20 AM
#63
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.
sr. member
Activity: 337
Merit: 263
August 06, 2010, 06:59:18 AM
#62
Oh, that's a part in the code my patch doesn't touch. You could try to remove line 2741 (CRITICAL_BLOCK(cs_main)).
newbie
Activity: 18
Merit: 0
August 06, 2010, 05:00:52 AM
#61
Here's the output on stderr:
Code:
bitcoind: main.cpp:2741: void BitcoinMiner(): Assertion `("break caught by CRITICAL_BLOCK!", !fcriticalblockonce)' failed.
sr. member
Activity: 308
Merit: 256
August 06, 2010, 02:50:03 AM
#60
Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU.
When the difficulty changed, the first machine in my group to generate a block was the slowest one running the stock client (800 MHz E-machine) and it hadn't generated anything in over a week itself. So I guess every little bit helps, that's so many are interested in getting this to work on their machine.
sr. member
Activity: 337
Merit: 263
August 05, 2010, 11:38:53 PM
#59
Yes, test is single threaded. Is there any output on stderr? From the coredumps I can tell that there must be some output.

The problem seems to be hard to debug, though. Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU.
newbie
Activity: 18
Merit: 0
August 05, 2010, 10:49:32 PM
#58
The test program does not fail
Code:
$ ./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.
sr. member
Activity: 337
Merit: 263
August 05, 2010, 10:06:14 AM
#57
That's not a real crash this time. It's an assert that fails in the miner. Most likely assert(hash == pblock->GetHash());. Can you run the test programm (explained in https://bitcointalksearch.org/topic/m.7096 If it fails, can you change -march=amdfam10 back to -march=native in makefile.unix, rm cryptopp/obj/*.o and recompile everything? What cpu are you running it on?
newbie
Activity: 18
Merit: 0
August 05, 2010, 09:35:50 AM
#56
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:
Code:
#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.
newbie
Activity: 18
Merit: 0
August 05, 2010, 02:40:16 AM
#55
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.
sr. member
Activity: 337
Merit: 263
August 04, 2010, 09:43:26 AM
#54
Oh thats easy: Get two nodes on a seperate network and connect them using -connect=other_nodes_ip and a seperate/empty datadir.
full member
Activity: 141
Merit: 100
August 04, 2010, 09:34:44 AM
#53
Just a comment that this would be easier to test if difficulty were set to '1' in the client.
sr. member
Activity: 337
Merit: 263
August 03, 2010, 11:00:49 PM
#52
GDB can also generate coredumps with the command generate-core-file. It might be useful to reconstruct the cause for the segfault. Please note, that the coredump might include your wallet so it's probably a good idea to run bitcoind on a seperate datadir.
newbie
Activity: 18
Merit: 0
August 03, 2010, 10:52:17 PM
#51
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.
sr. member
Activity: 337
Merit: 263
August 03, 2010, 08:03:07 PM
#50
Did your kernel write a coredump and if so can you mail me the binary + coredump to [email protected]?
newbie
Activity: 18
Merit: 0
August 03, 2010, 07:51:28 PM
#49
I did segfault according to dmesg:

Code:
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.
Pages:
Jump to: