Pages:
Author

Topic: An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only) - page 22. (Read 1958505 times)

PSL
member
Activity: 166
Merit: 10
Version 2.4

  • Support for getblocktemplate (GBT, BIP 22). With getwork deprecated and soon to be removed from Bitcoin, it was important to get this implemented, especially for testing solo mining. The getblocktemplate method is now used by default for protocol HTTP, but the miner should automatically switch to getwork if the newer method is not available. To force the miner to use getwork, a --no-gbt option is provided.

I found that for solo mining with cpuminer V1.4 I have to extend command line with parameter
--no-gbt or --coinbase-addr otherwise it will not connect to the "coin server":
Code:
[2014-05-21 13:05:06] No payout address provided
[2014-05-21 13:05:06] json_rpc_call failed, retry after 30 seconds

BTW, I think this is a cpuminer bug that it doesn't try to switch to getwork protocol and stays in never-ending loop waiting for a miracle...

I added --coinbase-addr because I think it can address a problem with wallet design, where it is not possible to export default key (at least I failed to find how to do it) and I have to keep backup of binary wallet that is far from perfect.

I test it at the moment, no block was found so far and that could be an indicator that something is wrong... Maybe I have only bad luck...

I found bfgminer notice, that when several clients are connected to the same "coin server" and are mining to the same address, than parameter --coinbase-sig has to be added

https://github.com/luke-jr/bfgminer, section SOLO MINING.

Is it true that --coinbase-sig with unique parameter has to be added when more clients are connected with the same address?? So far, I just configured all my clients with the same --coinbase-addr address but I am not sure if this is good idea because it is possible that they work on the same units and my computing power is reduces compared to configuration with --no-gbt (operation mode of older cpuminer)...
hero member
Activity: 842
Merit: 507
Version 2.4

  • Support for getblocktemplate (GBT, BIP 22). With getwork deprecated and soon to be removed from Bitcoin, it was important to get this implemented, especially for testing solo mining. The getblocktemplate method is now used by default for protocol HTTP, but the miner should automatically switch to getwork if the newer method is not available. To force the miner to use getwork, a --no-gbt option is provided.
  • It is now possible to tunnel Stratum through an HTTP proxy.
  • A --no-redirect option has been added, which makes the miner ignore redirection/reconnection requests coming from the server.
  • Startup error messages are now more descriptive.
  • The output of the --version option has been expanded to include additional build information.

The source code is, as always, available at GitHub. Source tarball and binaries are available at Sourceforge.
newbie
Activity: 36
Merit: 0


2.7MH/s with 800Mhz ... What do you mine and with what do you mine?

stratum+tcp://us-east2.multipool.us:7777 = scrypt
legendary
Activity: 1022
Merit: 1001
full member
Activity: 168
Merit: 100
What can I do?

Avoid posting in the wrong thread.

It should help.
newbie
Activity: 1
Merit: 0
I wanted to try out darkcoin-cpuminer-1.3-avx-aes and I fail to compile it on stock Ubuntu 14.04 64-bit server.

Here's what I do:
Code:
sudo apt-get install automake build-essential git libcurl4-gnutls-dev -y
git clone https://github.com/elmad/darkcoin-cpuminer-1.3-avx-aes.git
cd darkcoin-cpuminer-1.3-avx-aes
./autogen.sh
./configure CFLAGS="-O3"
make -j 8
And I get the following errors.

What can I do?
hero member
Activity: 842
Merit: 507
Any idea why I can't seem to get cpuminer to work solo mining?
It crashes right after minerd.exe executes.   I have no problems pool mining.  
Code:
minerd.exe --freq=850 --gc3355=COM3 --gc3355-chips=5 -o 192.168.0.100:35882 -u user.worker -p pass
Wrong thread. The cpuminer discussed in this thread is for CPU mining only.

For some reason I'm having trouble mining MemoryCoin. Keep getting json errors.
Version cpuminer 2.3.3
libcurl/7.35.0 zlib/1.2.8
I'm using mmcpool.com
Has anyone else had this problem?
MemoryCoin is not currently supported. If you are using a fork of this project, you should contact its author.
newbie
Activity: 39
Merit: 0
For some reason I'm having trouble mining MemoryCoin. Keep getting json errors.

Version cpuminer 2.3.3
libcurl/7.35.0 zlib/1.2.8

I'm using mmcpool.com

Has anyone else had this problem?
hero member
Activity: 658
Merit: 500
Any idea why I can't seem to get cpuminer to work solo mining?

It crashes right after minerd.exe executes.   I have no problems pool mining. 

Code:
minerd.exe --freq=850 --gc3355=COM3 --gc3355-chips=5 -o 192.168.0.100:35882 -u user.worker -p pass
full member
Activity: 210
Merit: 100

Anyway, as you can see from config.log, the configure script detects "x86_64-unknown-linux-gnu" as the target, which conflicts with your compiler being for x86. Maybe try passing --target=i686-unknown-linux-gnu to configure.

Thanks ! Now it work !  Grin

As soon as possible I'll install the Slackware 64 bits version on this PC


hero member
Activity: 842
Merit: 507

It looks like something is wrong with your environment. You say that you're on an x86 version of Slackware, and gcc seems to confirm that:
Code:
Target: i486-slackware-linux
But then why do arch and uname report "x86_64" as the architecture?

Because the AMD Sempron is a 64bits?

As far as I know, that's not how it works. arch should report the architecture in use, not what the hardware is or may be capable of. As a matter of fact, x86 and x86_64 are two distinct architectures; you cannot run a 64-bit binary if you're using a 32-bit kernel. Are you running a 64-bit kernel with a 32-bit userspace, by any chance?

Anyway, as you can see from config.log, the configure script detects "x86_64-unknown-linux-gnu" as the target, which conflicts with your compiler being for x86. Maybe try passing --target=i686-unknown-linux-gnu to configure.

Previously I've built the AVR tool chain without problem (GCC, binutils, AVRlibC, etc...) on this configuration.
http://www.nongnu.org/avr-libc/
The compilation of "cgminer" was also OK.
Unfortunately that's not very relevant here, as cgminer does not need to make fine distinctions between x86 and x86_64.
full member
Activity: 210
Merit: 100

It looks like something is wrong with your environment. You say that you're on an x86 version of Slackware, and gcc seems to confirm that:
Code:
Target: i486-slackware-linux
But then why do arch and uname report "x86_64" as the architecture?
 

Because the AMD Sempron is a 64bits?

Code:
uname --help
....
-m, --machine            print the machine hardware name
...

Code:
$ uname -m

x86_64



Previously I've built the AVR tool chain without problem (GCC, binutils, AVRlibC, etc...) on this configuration.

http://www.nongnu.org/avr-libc/


The compilation of "cgminer" was also OK.





hero member
Activity: 842
Merit: 507
3.10.17 #2 SMP Fri Feb 14 16:45:28 CST 2014 x86_64 AMD Sempron(tm) Processor LE-1200 AuthenticAMD GNU/Linux

So I run a Slackware 32 on a 64 CPU  Shocked

It looks like something is wrong with your environment. You say that you're on an x86 version of Slackware, and gcc seems to confirm that:
Code:
Target: i486-slackware-linux
But then why do arch and uname report "x86_64" as the architecture?

Out of curiosity, I tried installing Slackware 14.1 in QEMU, and arch reported i686 as expected. I was able to build cpuminer just fine.
full member
Activity: 210
Merit: 100


Please also provide the full output of "make clean && make"

http://pastebin.com/jvXKaNPy

Quote
as well as the output of the following:
Code:
gcc -dM -E - < /dev/null | sort

http://pastebin.com/kYzxAmj4


Quote
EDIT: You are using the x86_64 version of Slackware 14.1, right? Please provide the output of "uname -a".

Funny that you mention that - I've just realised today that the AMD Sempron was a 64  Embarrassed

3.10.17 #2 SMP Fri Feb 14 16:45:28 CST 2014 x86_64 AMD Sempron(tm) Processor LE-1200 AuthenticAMD GNU/Linux

So I run a Slackware 32 on a 64 CPU  Shocked

hero member
Activity: 842
Merit: 507
Please provide the contents of config.log and the full output of make (use a pastebin).

Ok, http://pastebin.com/TR9wbbnw

Quote
Are you building from the tarball or from the git repo?

From tarball, "pooler-cpuminer-2.3.3.tar.gz"

Please also provide the full output of "make clean && make", as well as the output of the following:
Code:
gcc -dM -E - < /dev/null | sort

EDIT: You are using the x86_64 version of Slackware 14.1, right? Please provide the output of "uname -a".
full member
Activity: 210
Merit: 100

Please provide the contents of config.log and the full output of make (use a pastebin).

Ok,

http://pastebin.com/TR9wbbnw

Quote
Are you building from the tarball or from the git repo?

From tarball, "pooler-cpuminer-2.3.3.tar.gz"

/EDIT/

Compiled on RaspBerry PI with the same distribution, Slackware14.1 ARM, it work  Grin  Huh

hero member
Activity: 842
Merit: 507
I can't seem to get this to connect, it times out every time. I've tried the following.

Code:
minerd.exe --url=stratum+tcp://multi.ghash.io:3333 --userpass=strangerhacks.intel:intel
Code:
minerd.exe -o stratum+tcp://multi.ghash.io:3333 -O strangerhacks.intel:intel
Code:
minerd.exe -o stratum+tcp://multi.ghash.io:3333 -u strangerhacks.intel -p intel

I've also tried with and without .exe at the end and that doesn't do anything at all, I've tried with a password and without a password, I've also tried on ltc.ghash.io and I even tried to mine SHA-256 by adding --algo=sha256d to the end of the three lines above and without fail, it results in a timeout error.

I tried pinging all URL's and they all result in less then 70 milliseconds.

The above lines seem to work fine for me.  This could be the same strange issue discovered by Massimo80.  Could you please try with the libcurl DLL from cpuminer 2.3.2 (rename it as needed so that it overwrites the DLL shipped with the 2.3.3 binary) and see if that solves the problem for you?
newbie
Activity: 28
Merit: 0
I can't seem to get this to connect, it times out every time. I've tried the following.

Code:
minerd.exe --url=stratum+tcp://multi.ghash.io:3333 --userpass=strangerhacks.intel:intel
Code:
minerd.exe -o stratum+tcp://multi.ghash.io:3333 -O strangerhacks.intel:intel
Code:
minerd.exe -o stratum+tcp://multi.ghash.io:3333 -u strangerhacks.intel -p intel

I've also tried with and without .exe at the end and that doesn't do anything at all, I've tried with a password and without a password, I've also tried on ltc.ghash.io and I even tried to mine SHA-256 by adding --algo=sha256d to the end of the three lines above and without fail, it results in a timeout error.

I tried pinging all URL's and they all result in less then 70 milliseconds.

Any ideas? I'm currently mining with CudaMiner using the following and it's working just fine so it's not the pool.

Code:
cudaminer.exe -o stratum+tcp://multi.ghash.io:3333 -O strangerhacks.intel:intel

If it helps, I have an Intel 3630QM 2.4GHz i7
hero member
Activity: 842
Merit: 507
I've tried to compile from sources (on Slackware 14.1) and got these errors:
[....]
Please provide the contents of config.log and the full output of make (use a pastebin). Are you building from the tarball or from the git repo?
full member
Activity: 210
Merit: 100
Hi,

I don't know if the right place to ask about this - I've tried to compile from sources (on Slackware 14.1) and got these errors:



[....]

sha2.c:(.text+0x3e64): undefined reference to `sha256_use_4way'
sha2.c:(.text+0x9645): undefined reference to `sha256d_ms_4way'
minerd-scrypt.o: In function `scanhash_scrypt':
scrypt.c:(.text+0x4e): undefined reference to `sha256_use_4way'
scrypt.c:(.text+0x6ca): undefined reference to `scrypt_core'
scrypt.c:(.text+0xa81): undefined reference to `sha256_transform_4way'
scrypt.c:(.text+0xa9f): undefined reference to `sha256_init_4way'
scrypt.c:(.text+0xbce): undefined reference to `sha256_transform_4way'
scrypt.c:(.text+0xbda): undefined reference to `sha256_init_4way'
scrypt.c:(.text+0xd02): undefined reference to `sha256_transform_4way'
scrypt.c:(.text+0xd3a): undefined reference to `sha256_transform_4way'
scrypt.c:(.text+0xddb): undefined reference to `sha256_transform_4way'
scrypt.c:(.text+0xe09): undefined reference to `sha256_transform_4way'
scrypt.c:(.text+0xea0): undefined reference to `scrypt_core'
scrypt.c:(.text+0xeb7): undefined reference to `scrypt_core'
scrypt.c:(.text+0xec7): undefined reference to `scrypt_core'
scrypt.c:(.text+0xed7): undefined reference to `scrypt_core'
scrypt.c:(.text+0xf25): undefined reference to `sha256_transform_4way'
scrypt.c:(.text+0xf44): undefined reference to `sha256_transform_4way'
scrypt.c:(.text+0xf60): undefined reference to `sha256_transform_4way'
scrypt.c:(.text+0xfa1): undefined reference to `sha256_transform_4way'
collect2: error: ld returned 1 exit status
make[2]: *** [minerd] Error 1

[.....]






Pages:
Jump to: