Could you make a little code improvement, because now the only way to use cudaminer with screen
is to run pure screen, and execute cudaminer from screen session. It works fine.
But if you want to have the same, but executed from shell script - there is a SIGHUP signal, which terminates screen completely.
root@linux:~/cpuminer-master# gdb screen
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/screen...(no debugging symbols found)...done.
(gdb) set args ./minerd -V
(gdb) run
Starting program: /usr/bin/screen ./minerd -V
[screen is terminating]
Program received signal SIGHUP, Hangup.
0x00007f9de428f7e0 in __pause_nocancel () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
Hi, I'm not sure what you are trying to achieve. I can run minerd in screen with no problem at all, and even script it (with screen -dm minerd [OPTIONS]), and never had an issue. Regarding the gdb output you posted, you will probably get the same result if you try to run a simple program like ls instead of minerd -V. |
|
|
|
Seems it can't find inttypes.h. [...] gcc (GCC) 3.4.4 (msys special)
Copyright (C) 2004 Free Software Foundation, Inc.
It looks like your compiler is pretty old. I would try using a more recent version (preferably 4.6 or later). |
|
|
|
I'm trying to compile the latest version released yesterday and running into an issue. I'm getting the "checking whether the C compiler works... no" error. [...] configure: error: C compiler cannot create executables
[...] x86_64-w64-mingw32-gcc.exe: error: unrecognized command line option '-03'
Q: When running configure I get the error "C compiler cannot create executables".
A: Make sure you typed CFLAGS="-O3" with a big O, not with a zero.
|
|
|
|
Ehhemmmmm,,,,cpuminer is also being used for non-CPU applications such as our 5 chip Gridseed ASIC miners.
Just like I said: there exist forks of this project that are modified to work with ASIC chips. But this is not the place to discuss them, as I don't maintain those forks. Different versions, ours - 2.3.2 , yours - 2.3.3
They don't make it clear that 2.3.3 is strictly for CPU in the data about it so...one is left to figure it out for ones self via extrapolation - guessing ;]
Unfortunately it is not that simple. The fork you are talking about retains the same version numbering scheme of the original cpuminer, so you definitely can't distinguish the fork from the original by the version number alone. What happened is that someone forked version 2.3.2 of the miner discussed in this thread (which is a CPU-only miner) and modified it so that it could interface with ASIC chips, but didn't bother to change the name of the program or even the version. Hence the confusion. |
|
|
|
I have a gridseed with me and i'm trying to figure out how can I mine with it without using a controller, just to connect to the usb and creates a virtual com port, any ideas. (litecoin)
anyone know how to mine both litecoin and bitcoin on a gridseed 5 chip miner in windows
Will the latest version speed up the hash rate of my GC3355 5 chip ASIC miners?
I'm sorry, but you are all in the wrong thread. This is the thread for cpuminer, which (as the name suggests) is a CPU-only miner. There are forks of this project that are modified to handle Gridseed chips, but this is not the right thread to discuss them. Please try here or here or here, or open your own thread. |
|
|
|
Version 2.3.3This is a very minor update, mostly consisting of small bug fixes. It introduces no new functionalities or speed improvements. - The --url/-o option is now mandatory. (The miner no longer defaults to connecting to localhost:9332.)
- The miner will no longer try to switch to Stratum if it is connecting via an HTTP proxy, as it is impossible to use Stratum over HTTP.
- Fixed CPU affinity on FreeBSD and scheduling policy change on Linux.
- Compatibility fixes for ICC and for compiling on various platforms, including old versions of Solaris and OS X.
- A man page for minerd has been added.
The source code is, as always, available at GitHub. Source tarball and binaries are available at Sourceforge.
|
|
|
|
|
It is clearly stated on the website, but let me repeat it for the sake of clarity: this miner is to be considered deprecated, as it only supports the old getwork protocol. It is no longer officially supported at litecoinpool.org since August 27, 2013.
|
|
|
|
From a practical viewpoint it is unlikely that anybody would be able to hash every nonce in a given block given the present state of available hardware with the possible exception of banks of super computers deep in the bowels of the NSA or other government entity somewhere.
That is incorrect. It only takes about 72 MH/s to check every possible nonce in less than a minute, and dual-CPU systems are already able to attain such rates for SHA-256d. |
|
|
|
I understand most of what's going on but I've got a few questions about what I've found in the code. Actually, it's a question about some curious code. Here's the extract from cpu-miner.c. I've removed the irrelevant portions. static void *miner_thread(void *userdata)
{
. . .
uint32_t end_nonce = 0xffffffffU / opt_n_threads * (thr_id + 1) - 0x20;
. . .
if (memcmp(work.data, g_work.data, 76)) {
memcpy(&work, &g_work, sizeof(struct work));
work.data[19] = 0xffffffffU / opt_n_threads * thr_id;
} else
work.data[19]++;
. . .
}
This code appears to set up an initial start and end boundary for nonce checking on new work. It also seems to be attempting some cleverness to avoid doing expensive computation on 'long long int' type. I'm assuming that the intent is to set start and end boundaries at the beginning of each thread's block (relative offset of 0) and then then end at one by before the start of the next thread's block. That's not what the effect is and the following block shows: thread = 0 start_nonse = 0x00000000 end_nonse = 0x1fffffdf
thread = 1 start_nonse = 0x1fffffff end_nonse = 0x3fffffde
thread = 2 start_nonse = 0x3ffffffe end_nonse = 0x5fffffdd
thread = 3 start_nonse = 0x5ffffffd end_nonse = 0x7fffffdc
thread = 4 start_nonse = 0x7ffffffc end_nonse = 0x9fffffdb
thread = 5 start_nonse = 0x9ffffffb end_nonse = 0xbfffffda
thread = 6 start_nonse = 0xbffffffa end_nonse = 0xdfffffd9
thread = 7 start_nonse = 0xdffffff9 end_nonse = 0xffffffd8
I created a programme that output the boundaries of each thread block and this is what I got. The purpose of that piece of code is to share the same work unit (block header) between all miner threads, so that we don't need to fetch different work (if using getwork) or to compute a different Merkle root hash (if using Stratum) for every thread. This is accomplished by partitioning the nonce space and by assigning a distinct nonce range to each thread, so that no two ranges overlap. Because of how mining works, the search over the nonce space doesn't have to be exhaustive, meaning that it is OK if we don't check all possible nonces before fetching new work. The gap that you see between nonce ranges is needed to avoid checking some nonces twice, as some of the core algorithm implementations may compute more hashes than requested (because of parallelization). The fact that we may skip checking a tiny fraction (0.000004%) of the nonce space is far from being a problem. |
|
|
|
--time-limit maximum time (s) to mine before exiting the program. Would be cool to see --time-limit parameter in cpuminer, too. The same result can be obtained by using the timeout command from GNU coreutils (also available via Cygwin and Homebrew). |
|
|
|
Checksums in the first post don't match with the files, more specifically with the win32 one... Anything wrong?
Re-downloaded it just now from Sourceforge, and it matches. $ sha256sum pooler-cpuminer-2.3.2-win32.zip
5cd04f0324f9f18f4bd989e981b1ac72edb68bf6b76498e616d22cfe0a798122 pooler-cpuminer-2.3.2-win32.zip
|
|
|
|
any reason why the total pool hash rate dropped suddenly?
The same reason the total network hash rate dropped suddenly, I guess. Probably just chain hoppers. |
|
|
|
My GPU mining through cgminer is going fine to my pool, however CPUMiner is acting strange. It is not showing me sending any hashes. This is what it is showing almost all the time: https://i.imgur.com/eakS25T.pngWhat's going on? If you send me the exact parameters you're using to connect I can give it a try. minerd.exe -o http://127.0.0.1:8332 -u <my BTC ID> -p <anything> I am connecting to middlecoin.com:3333 within my Mining Proxy that is listening on 8332. Which fork of slush's proxy are you using, exactly? Are you also connecting cgminer through the proxy, and if yes with what parameters? Does the issue also arise if you stay connected to the getwork port instead of letting it switch to Stratum (pass --no-stratum to minerd)? |
|
|
|
minerd.exe – url=stratum+tcp://stratum7.dogehouse.org:9090 –userpass=ikinga:x
Please make sure those options start with two hyphens ( --), not with a Unicode dash, and that there is no space after the hyphens. My GPU mining through cgminer is going fine to my pool, however CPUMiner is acting strange. It is not showing me sending any hashes. This is what it is showing almost all the time: https://i.imgur.com/eakS25T.pngWhat's going on? If you send me the exact parameters you're using to connect I can give it a try. |
|
|
|
Is mining on the CPU less effective than GPU, and that is why solutions aren't coming up as commonly as they do in a GPU based miner?
It depends on what you mean by "effective", but I would say it is. Mining with a "good" GPU is certainly more efficient than mining with a CPU, at least. For a more complete answer you should consult the mining hardware comparison. The rate at which solutions get accepted depends both on your hash rate and on the share difficulty set by the pool. In general you need not care about it, especially given that share difficulty can vary dynamically. xxxxx\pooler-cpuminer-2.3.2-win64\minerd.exe --url=stratum+tcp://de2.miningpool.co:4101 --userpass=xx:xx
Any other commands to expand on this as after 5 minutes it gets disconnected.
No. If it gets disconnected it's almost certainly either the pool's or your Internet connection's fault (most probably the pool's). I'm always happy to test mining servers for compatibility, but I cannot even connect to the one mentioned above. |
|
|
|
I have a quad core Intel chip, and CPUMiner is doing four threads (I assume this is how it's supposed to work, 1 thread per core?) I do not have a hyper-threaded processor.
Question 1: 1 thread to per 1 non-hyperthreaded core?
I'm not sure I understand what the question is. Anyway, cpuminer defaults to starting as many mining threads as logical CPU cores, which normally gives the best results performance-wise. If your CPU does not support hyper-threading, then logical cores are basically the same as physical cores; if it does support hyper-threading, you will have 2 logical cores per physical. Question 2: I don't always see "accepted: x/y (%) xx.xx khash/s (yay!!!)". How often is this supposed to come up? I assume it's supposed to happen after every thread computes some khashes, but it isn't. Some additional information on this process would be very appreciated.
You will see that message every time a solution (a share if you're mining in a pool) is accepted or rejected by the server. Since finding solutions is a random process, the message is not supposed to come up at regular intervals. I got accepted (100%) Yay!!!.......what does it mean? found a block or share
If you're mining solo it means you found a block, if you're mining in a pool it means you found a share. The percentage refers to how many of the solutions you've submitted so far have been accepted. |
|
|
|
is there any way to unlock my payment address once it has been locked?
In most cases it is possible, but you have to go through support. Please send an email to the address you will find at the bottom of the Help page. |
|
|
|
One more question plz.
The pool now implement VAR DIFF automatically. While can one fix a DIFF for each of his worker, manually and seperately?(Like some BTC pools I've mined with.)
Since I got a new problem: Due to unstable network, some share lost -> DIFF goes lower -> network load heavier --> more share lost --> DIFF even lower.
I think for some guys with a unstable network(like me), income variability is not so important as network load.
Usually when people ask for the ability to manually set share difficulty it's because they don't understand the underlying math, and naively think it's intrinsically better to have a low or high share difficulty. I think this is the first time I hear a semi-valid justification for such a feature. However, if your network is that unstable, then you probably have much more serious problems (such as the amount of time you spend hashing stale data) than those caused by an unsuitably low share difficulty. Actually, No. The problem arises from flow control of my network proxy --- too many share submissions result in proxy temporarily refusing. I'm also mining in a higher DIFF pool(fixed, but higher, 64 v.s. 2 of litecoinpool.org), stale rate under 3%. (long pool too) Your issue is a getwork one, and the getwork interface has been deprecated for over 4 months now. This means that it is not officially supported anymore, and it is eventually going to be removed altogether. If for some reason you want to use it, feel free to do so while it's still available, but don't expect it to work reliably. The getwork protocol itself has many limitations and doesn't lend itself to scalability. what is the average stale rate for you guys? my gpus (7950s') are all averaging around 1.2-1.3% stale rate and was wondering if it is a little high?
The pool average right now is 0.5%, with some users going as low as 0.03%. However, software latency is sometimes unavoidable when GPU mining, so a stale rate around 1% is usually considered acceptable for GPU systems. Please note that this kind of latency is not due to your network connection or to the pool, but to the miner itself. would lowering the intensity or clock settings affect the stale rate? its weird because i recently build a new rig with 3x 280x and they are averaging only around 0.10%. It's possible. As you noticed, this can be very system-dependent, so you need to experiment in order to find out. |
|
|
|
One more question plz.
The pool now implement VAR DIFF automatically. While can one fix a DIFF for each of his worker, manually and seperately?(Like some BTC pools I've mined with.)
Since I got a new problem: Due to unstable network, some share lost -> DIFF goes lower -> network load heavier --> more share lost --> DIFF even lower.
I think for some guys with a unstable network(like me), income variability is not so important as network load.
Usually when people ask for the ability to manually set share difficulty it's because they don't understand the underlying math, and naively think it's intrinsically better to have a low or high share difficulty. I think this is the first time I hear a semi-valid justification for such a feature. However, if your network is that unstable, then you probably have much more serious problems (such as the amount of time you spend hashing stale data) than those caused by an unsuitably low share difficulty. what is the average stale rate for you guys? my gpus (7950s') are all averaging around 1.2-1.3% stale rate and was wondering if it is a little high?
The pool average right now is 0.5%, with some users going as low as 0.03%. However, software latency is sometimes unavoidable when GPU mining, so a stale rate around 1% is usually considered acceptable for GPU systems. Please note that this kind of latency is not due to your network connection or to the pool, but to the miner itself. |
|
|
|
Here's what you need for the CPU miner. I'm running four threads, two per CPU core. Increase the number after -t for more threads. Replace stratum+tcp://www.shibepool.com:3333 with your pool server and port number. (This is a small pool, just over 800 workers currently.)
minerd -a scrypt -t 4 -s 6 -o stratum+tcp://www.shibepool.com:3333 -O UserName.WorkerName:YourPassword
It's been said before, but let me repeat it: the -s option does nothing when you mine in a pool (both when using Stratum and when using long polling). It only makes sense to use it if you are mining solo. Also, for optimal performance it is usually best to have exactly one thread per logical (as opposed to physical) core, which is what cpuminer does by default. The -t option is normally used to start fewer threads, so as to limit the system load. |
|
|
|
|
Show Posts
