Latest posts of: RudeDude

Show Posts
Pages: [1]

Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx

on: July 31, 2011, 02:29:41 PM

Quote from: d3m0n1q_733rz on July 31, 2011, 12:02:13 PM Quote from: zaytsev on July 31, 2011, 09:21:26 AM 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

Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx

on: July 30, 2011, 11:53:09 PM

Quote from: d3m0n1q_733rz on July 30, 2011, 10:56:51 PM 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 ... 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.

Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx

on: July 29, 2011, 01:08:01 PM

Quote from: ckolivas on July 29, 2011, 05:20:53 AM

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]
--------------------------------------------------------------------------------

Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx

on: July 28, 2011, 09:48:04 PM

Quote from: plantucha on July 28, 2011, 09:35:43 PM 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 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

Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx

on: July 27, 2011, 11:24:53 PM

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.

Bitcoin / Bitcoin Discussion / Re: *** ALERT *** version 0.3.6

on: July 29, 2010, 08:35:54 PM

Ha! One of the changes in there is updated some v "0.3.3" stuff to "0.3.6" but that isn't the important part of the update. :-)

Bitcoin / Bitcoin Discussion / Re: Post Your Hash/Sec and Hardware

on: July 26, 2010, 07:58:47 PM

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.

Bitcoin / Development & Technical Discussion / Re: Hard disk usage

on: July 24, 2010, 06:41:11 PM

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.

Bitcoin / Development & Technical Discussion / Re: Sample account system using JSON-RPC needed

on: July 16, 2010, 08:23:48 PM

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.

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."

Bitcoin / Development & Technical Discussion / Re: Sample account system using JSON-RPC needed

on: July 16, 2010, 08:18:45 PM

bitcoinmarket.com is doing all of these things now. perhaps the author of that site can share some code as well.

Bitcoin / Bitcoin Discussion / Re: Proof-of-work difficulty increasing

on: July 16, 2010, 04:59:04 PM

Quote from: gould on July 13, 2010, 09:30:59 PM 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.

Pages: [1]