Search content
Sort by
Showing 11 of 11 results by RudeDude
Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx
d3m0n1q_733rz, why wouldn't you create a fork on github? would be easier then copy-pasting and less error-prone.
A) I can't actually program from scratch and most of my changes or just logic based.B) Almost nobody gives me input on how my changes affect their hashing anyway.
C) People might end up sending me incessant requests for changes that I couldn't keep up with.
Sorry to say but that version dropped performance by about 3-4%. There is definitely some variance in the cgminer speed reporting from moment to moment (from 6.7 to 7.4 Mh/s total for this 2 core setup) but over a ~2-3min period it seems to average out to reliable numbers.
Since I'm providing some feedback I should prolly tell you some hardware & compile details:
Code:
CFLAGS = -O3 -ffast-math -funroll-loops -mtune=native -march=native -msahf
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz
stepping : 11
cpu MHz : 2992.227
cache size : 4096 KB
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon
pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
dca lahf_lm tpr_shadow vnmi flexpriority
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz
stepping : 11
cpu MHz : 2992.227
cache size : 4096 KB
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon
pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
dca lahf_lm tpr_shadow vnmi flexpriority
Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx
Hey, I've been working on the hashing asm, as I said before, by removing redundancies of functions and register moves, using logic to modify source and destinations to take advantage of processor hardware optimizations and doing some of the easy math myself so the processor doesn't have to. Here's what I've done so far. It's not much, but it works. Don't go changing the github source just yet though. For now, copy-paste this to replace your existing sha256_sse4_amd64.asm file. For those of you without SSE4.1 (such as AMD users), copy paste this into you sse2_amd64 file instead and search-replace all uses of movntdqa with movdqa so the quick memory moves aren't used.
I pasted your ASM into sha256_xmm_amd64.asm and changed "movntdqa" to "movdqa" like you said for sse2. But I get a linker error.
Code:
...
cgminer-sha256_sse2_amd64.o: In function `scanhash_sse2_64':
sha256_sse2_amd64.c:(.text+0x4fb): undefined reference to `CalcSha256_x64'
sha256_sse2_amd64.c:(.text+0x50b): undefined reference to `CalcSha256_x64'
collect2: ld returned 1 exit status
...
cgminer-sha256_sse2_amd64.o: In function `scanhash_sse2_64':
sha256_sse2_amd64.c:(.text+0x4fb): undefined reference to `CalcSha256_x64'
sha256_sse2_amd64.c:(.text+0x50b): undefined reference to `CalcSha256_x64'
collect2: ld returned 1 exit status
...
I had to change "CalcSha256_x64_sse4" to "CalcSha256_x64" in two spots. Then the compile went just fine. I'm running now to see if it's any faster and if any work actually gets accepted bu t hopefully it's bug free.
btw, doesn't the assembler do basic inline math before assembling?
P.S. Hashrate looks really close to the same but I did get a work unit accepted just now.
EDIT: so the increase in speed, if any, is around 1% increase maybe slightly more. I only have two cores at 3.5 Mh/s each so it's hard to see the difference on the scale of Mhash/s.
Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx
As for CPU mining in 1.5.x+, I find the rate of accepted shares is the same crap rate as previous versions, as far as CPU mining goes. It's no worse than it ever was, but the efficiency is higher (efficiency being accepted shares / requests, NOT the reject rate).
I can confirm 1.5.2 does not drop hashing speed anymore (Linux, Ubuntu 10.04, CPU mining only). I ran one all night and the speed is still as expected. My accept/rejects are reasonable unlike what others have reported. Here it is:
Code:
cgminer version 1.5.2 - Started: [2011-07-28 23:09:41]
--------------------------------------------------------------------------------
[(5s):6.8 (avg):6.8 Mh/s] [Q:1335 A:48 R:4 HW:0 E:4% U:0.08/m]
TQ: 2 ST: 2 LS: 0 SS: 0 DW: 1331 NB: 88 LW: 1517 LO: 0 RF: 0 I: 0
Connected to http://api.bitcoin.cz:8332 as user _________._____
Block: 0000082a6635d024f3914d9b6cb27760... Started: [09:00:19]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
CPU 0: [3.4 / 3.4 Mh/s] [Q:761 A:19 R:1 HW:0 E:2% U:0.03/m]
CPU 1: [3.4 / 3.4 Mh/s] [Q:758 A:29 R:3 HW:0 E:4% U:0.05/m]
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
[(5s):6.8 (avg):6.8 Mh/s] [Q:1335 A:48 R:4 HW:0 E:4% U:0.08/m]
TQ: 2 ST: 2 LS: 0 SS: 0 DW: 1331 NB: 88 LW: 1517 LO: 0 RF: 0 I: 0
Connected to http://api.bitcoin.cz:8332 as user _________._____
Block: 0000082a6635d024f3914d9b6cb27760... Started: [09:00:19]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
CPU 0: [3.4 / 3.4 Mh/s] [Q:761 A:19 R:1 HW:0 E:2% U:0.03/m]
CPU 1: [3.4 / 3.4 Mh/s] [Q:758 A:29 R:3 HW:0 E:4% U:0.05/m]
--------------------------------------------------------------------------------
Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx
I can confirm. CPU mining doesn't work
1.5.&up i have to go back to 1.4 and it works
with 1.5 only 4% was acepted 96% rejected
- CPU: AMD Phenom X6
- GPU: 4x HD 6790 oced to 900 MHz (Mem 300 MHz)
- ubuntu 64 bit natty
- Catalyst 11.6 with SDK 2.4
1.5.&up i have to go back to 1.4 and it works
with 1.5 only 4% was acepted 96% rejected
- CPU: AMD Phenom X6
- GPU: 4x HD 6790 oced to 900 MHz (Mem 300 MHz)
- ubuntu 64 bit natty
- Catalyst 11.6 with SDK 2.4
Have you tried forcing other CPU algorithms with the "-a" option? Perhaps it is particular to a algorithm running on your CPU architecture? You might need to look at the debug output for some of the rejects to get an idea why they are failing. Also, what pool are you connecting to?
-- RD
Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx
I'm loving cgminer, in part because the binary just plain runs on Ubuntu 10.04 
And the ncurses display rocks!
(I need to fight with the CUDA drivers to get OpenCL working if I want GPU mining.)
Has anybody noticed the hashrate dying off after running for several hours? I've also noticed something that _might_ be related... Right after starting the debug display outputs a line or two every second. I usually go back to normal display if things are working and after a few new blocks are detected on the network I go to look at the debug display and now it's flying by super fast. It's almost as if something is looping an extra time (therefore hitting the debug output more often) after running for a while.
Anyway, thanks for coding this up. I'm going to scrape together a few bitpennies to donate.
--RD
Edit: P.S. I wanted to ask if anyone has tried to compile a Windows 64bit version? I'd like to run cgminer instead of guiminer but the sse2_64 is much faster.
And the ncurses display rocks!(I need to fight with the CUDA drivers to get OpenCL working if I want GPU mining.)
Has anybody noticed the hashrate dying off after running for several hours? I've also noticed something that _might_ be related... Right after starting the debug display outputs a line or two every second. I usually go back to normal display if things are working and after a few new blocks are detected on the network I go to look at the debug display and now it's flying by super fast. It's almost as if something is looping an extra time (therefore hitting the debug output more often) after running for a while.
Anyway, thanks for coding this up. I'm going to scrape together a few bitpennies to donate.
--RD
Edit: P.S. I wanted to ask if anyone has tried to compile a Windows 64bit version? I'd like to run cgminer instead of guiminer but the sse2_64 is much faster.
I upgraded to the x64 optimized client on a box that I run on rare occasions:
Windows XP Pro x64, Intel Xeon X5550 @ 2.67GHz, 8 cores. - 10,400 khash/sec in the display, 9,000 in the hashmeter log.
The rate with stock client used to be about 4,300 khash/sec.
Windows XP Pro x64, Intel Xeon X5550 @ 2.67GHz, 8 cores. - 10,400 khash/sec in the display, 9,000 in the hashmeter log.
The rate with stock client used to be about 4,300 khash/sec.
Even with having most of the blocks the hard drive usage seems a little inefficient.
I've had my client offline for several days and just started it. It already had over 69,000 blocks and yet the hard drive was grinding for 2+ minutes solid before the counter started going up. (I even installed version 0.3.2.5 hoping the cached database stuff Satoshi added would help.)
Clearly the initial startup is doing some sort of block (re)verification for all blocks that is causing some synchronous reads and/or writes.
I've had my client offline for several days and just started it. It already had over 69,000 blocks and yet the hard drive was grinding for 2+ minutes solid before the counter started going up. (I even installed version 0.3.2.5 hoping the cached database stuff Satoshi added would help.)
Clearly the initial startup is doing some sort of block (re)verification for all blocks that is causing some synchronous reads and/or writes.
I should also point out that this site has some JSON code in Python.
http://www.alloscomp.com/bitcoin/
Specifically this code that checks the balance and sends it to a static address.
http://www.alloscomp.com/bitcoin/
Specifically this code that checks the balance and sends it to a static address.
Code:
#!/usr/bin/python
import jsonrpc
MyBCAddress = 'YOUR BITCOIN ADDRESS HERE'
b = jsonrpc.ServiceProxy("http://localhost:8332/")
bal = float(b.getbalance())
if bal > 0.01:
print "We have a balance of {0:.2f}BC. Sending...".format(bal)
b.sendtoaddress(MyBCAddress,bal)
else:
print "No coins here."
import jsonrpc
MyBCAddress = 'YOUR BITCOIN ADDRESS HERE'
b = jsonrpc.ServiceProxy("http://localhost:8332/")
bal = float(b.getbalance())
if bal > 0.01:
print "We have a balance of {0:.2f}BC. Sending...".format(bal)
b.sendtoaddress(MyBCAddress,bal)
else:
print "No coins here."
I'd be interested in seeing something like "expected bitcoins generated/day" next to (or in place of) the khash/s number. I'd rarely need to see the khash/s number since that won't change unless I make changes to the software or hardware.
I think the web c alc does a good job by showing likelyhoods based on khash speed:
http://www.alloscomp.com/bitcoin/calculator.php
That way you can see there is no guaranteed time horizon.