Heh, it'd still be Con's GPU miner, so I don't need to rename it  |
|
|
|
I'm still for CPU mining support being maintained (in spite of the fact that I don't use cgminer for cpu mining because ufasoft works better in Windows), but this might be the single best argument for removing CPU mining from cgminer. If someone is distributing this with a botnet, they probably wouldn't bother if it couldn't CPU mine since non-user processes can't GPU mine in WinVista/7 and plenty of XP machines don't have relevant hardware. That said, dishwara, please find out how to report this as a false positive to whoever controls "File Insight" before the other AV companies start copying the definition (not that they would do that, surely all of the AV companies find and research all of the different malwares on their own [just like they run and thoroughly test the executables which would obviousy show them that ufasoft and cgminer aren't malware]  ) I like it. In fact, I may just remove cpu mining from windows only, especially since windows cpu mining is so slow anyway. Then I can stop getting all those morons emailing me asking me to make private versions of cgminer (for which I've refused every single time). I don't want my name associated with something that someone manages to make a botnet. Perhaps this comment was overkill. Obviously it can still be used to make and distribute a botnet even as a gpu miner. However I don't know how anyone can stop their application being misused by being packaged with other software and its own batch file. That's why I've been releasing them all from the same place so people can know where they're coming from. |
|
|
|
I'm still for CPU mining support being maintained (in spite of the fact that I don't use cgminer for cpu mining because ufasoft works better in Windows), but this might be the single best argument for removing CPU mining from cgminer. If someone is distributing this with a botnet, they probably wouldn't bother if it couldn't CPU mine since non-user processes can't GPU mine in WinVista/7 and plenty of XP machines don't have relevant hardware. That said, dishwara, please find out how to report this as a false positive to whoever controls "File Insight" before the other AV companies start copying the definition (not that they would do that, surely all of the AV companies find and research all of the different malwares on their own [just like they run and thoroughly test the executables which would obviousy show them that ufasoft and cgminer aren't malware] ) I like it. In fact, I may just remove cpu mining from windows only, especially since windows cpu mining is so slow anyway. Then I can stop getting all those morons emailing me asking me to make private versions of cgminer (for which I've refused every single time). I don't want my name associated with something that someone manages to make a botnet. |
|
|
|
I just installed this on linuxcoin 0.2.1b to test. I've been getting a lot of empty queue's and 20% rejects with phoenix thanks to a lightning strike and crappy ISP fixes. I'm not seeing any rejects with cgminer. I do see this: [2011-08-19 19:51:20] Pool 1 communication failure, caching submissions
[2011-08-19 19:51:20] Stale share detected, discarding
[2011-08-19 19:51:23] Pool 1 communication resumed, submitting work
Is it just discarding and not recording rejected shares, or it really not processing and submitting them? Yes it detects that the share it has been trying to submit unsuccessfully for a while has gone stale in the time it was trying to submit it and decides it is better to give up trying to submit it. On the other hand, if you still want it to try and submit these shares indefinitely cgminer has the option --submit-stale to override that test. |
|
|
|
|
No windows 64 bit care factor included.
|
|
|
|
|
Excellent. Welcome to the moronic world that is windows virus management. Since you clearly DO know what cgminer is for, have fun working around that.
|
|
|
|
|
Why? Because someone has to make the code modular the way you describe.
|
|
|
|
It's a good idea, but it needs even more work on my part for the cpu mining  . If someone wants to write such an interface, be my guest, and I'll pull it into the tree. |
|
|
|
|
I'm also most open to pulling changes into my tree, and kind people like znort and others have already contributed code too.
|
|
|
|
Look, do you want to to know why we shouldn't remove CPU functionality from cgminer? It's simple. CPU mining is where a lot of us got our start. We couldn't afford to get decent graphics cards to mine with so we CPU mined and worked our way up to small quantities like .1 BTC where we invest it in something like Ponzie to build it up faster to get a graphics card.
In short, those who need some way to begin are the ones who will need this the most. The children; don't forget the children!
That keeps occurring to me to. However, it doesn't change the fact that code needs maintenance and effort and working on one thing means it sacrifices the time I have to work on another. Not to mention that people donate BTC for GPU mining code, which is hard to ignore as an incentive.  |
|
|
|
(lesson: roll back to 11.6)
11.8->11.6 yields me -2 Mh/s, but with the CPUs at roughly 0% now, that very small loss is perfectly bearable. Indeed in a MH/watt equation this makes a lot of sense since it will rise significantly. This was always what cgminer was supposed to be capable of. The code in cgminer itself should be incredibly low CPU overhead. It's the drivers and windows' pthread library which use up a lot of CPU. |
|
|
|
|
Hey phateus, just a head's up. Your cgminer code only worked for 2 vectors. I've updated it in my git tree to work with 1 and 4. Simple enough change.
|
|
|
|
Hi there... I configured the program with ./configure CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" on FreeBSD. But when I type make next, it showed up like this: make all-recursive
Making all in lib
make all-recursive
Making all in compat
Making all in jansson
Making all in ccan
gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib -I/usr/local/include -MT cgminer-util.o -MD -MP -MF .deps/cgminer-util.Tpo -c -o cgminer-util.o `test -f 'util.c' || echo './'`util.c
In file included from util.c:35:
miner.h:33:1: warning: "alloca" redefined
In file included from util.c:16:
/usr/include/stdlib.h:237:1: warning: this is the location of the previous definition
util.c: In function 'json_rpc_call_sockopt_cb':
util.c:268: error: 'SOL_TCP' undeclared (first use in this function)
util.c:268: error: (Each undeclared identifier is reported only once
util.c:268: error: for each function it appears in.)
util.c:268: error: 'TCP_KEEPCNT' undeclared (first use in this function)
util.c:271: error: 'TCP_KEEPIDLE' undeclared (first use in this function)
util.c:274: error: 'TCP_KEEPINTVL' undeclared (first use in this function)
*** Error code 1
Stop in /usr/home/users/xxxxxxx/xxxxxxxx/cgminer-1.5.6.
*** Error code 1
Stop in /usr/home/users/xxxxxxx/xxxxxxxx/cgminer-1.5.6.
*** Error code 1
Stop in /usr/home/users/xxxxxxx/xxxxxxxx/cgminer-1.5.6.
Could somebody please help? Thanks  No one's ever tried to compile it for freebsd before as far as I'm aware. It looks like freebsd will need some special defines to get it working. While I can generically put some in in the next release in the hope it works, I can't guarantee it will be fixed. |
|
|
|
|
Actually most of the CPU usage with GPU mining is related to driver stupidity. On Linux, you get close to zero CPU usage if you're using the 11.6 catalyst driver. However, they've ported the windows CPU usage to 11.7 and 11.8 drivers. So even on Linux if you use 11.7+, you get a lot of CPU usage. (lesson: roll back to 11.6). For those curious about -why- this is the case, they stupidly use an infinite number of sched_yield() calls to keep the cpu busy for a hot return back to the GPU. While this potentially can yield speed-ups through all sorts of means (during gaming for example), in mining it just chews up power and doesn't increase the hash rate in my testing.
|
|
|
|
When does cgminer disable and re-enable a pool?
I just checked on my miner and the pool was disabled for some reason. The pool came back up and cgminer didn't re enable it straight away. In my experience, it recovers pretty quickly when a pool is down and recovers in a short period of time. I haven't had a pool down for a long period of time. However, also in my experience, when a pool is down when you start it, it might remain disabled permanently if you don't manually enable it. Are you sure it didn't detect the pool as down during startup? Exactly. cgminer never disables a pool itself unless it's not responding when you first start it. The reason it disables a pool that doesn't respond is that you may have simply passed it invalid credentials and there's no point flooding the network repeatedly trying to communicate with a server under those circumstances. If at any time a pool goes down that IS enabled, it diverts the load elsewhere, but does NOT disable it. It then checks it at one minute intervals and if it comes back to life will divert the load back. It never disables an enabled pool by itself. |
|
|
|
|
Just a data point for those not aware, since I am a linux kernel CPU scheduler programmer as well. A modern CPU when idle uses a LOT LESS power than when it's running computation EVEN AT THE SAME FREQUENCY. All modern CPUs adjust power according to their requirements, even within the same frequency profile. It's a misconception to think that just because a CPU is running at low frequency that it's using the same amount of power whether idle or mining.
|
|
|
|
@ckolivas: The cpu-only miner still crashes when started with this bat-file: The CPU mining component of cgminer is annoying me as random bugs keep coming up, I have no incentive to work on it, and I am quite against CPU mining as a concept any more. Unless someone gives me a good reason to work on it any more, I'm going to recommend people go back to the original cpuminer code or ufasoft, and I will code out the cpu mining component of cgminer. Comments please! |
|
|
|
Hey, Great work on this! Takes pretty much all the features I had hacked into/worked around/etc. w/ Phoenix, and integrated them nicely. Currently in the process of rolling out cgminer across the whole cluster. One quickie... Right now, I do graph mHash/sec per GPU, and have various alarms that trigger. While options exist to get per-gpu stats as-is (e.g. --debug), they are not optimal. Right now the interval status line logging works great for me - it would be perfect if an option existed to also list the latest GPU stats as well. Something like: [2011-08-18 02:12:17] [ALL (5s):508.0 (avg):536.9 Mh/s] [Q:5 A:0 R:0 HW:0 E:0% U:0.00/m] [2011-08-18 02:12:17] [GPU0 (5s):204.0 (avg):214.9 Mh/s] [Q:5 A:0 R:0 HW:0 E:0% U:0.00/m] [2011-08-18 02:12:17] [GPU1 (5s):204.0 (avg):217.9 Mh/s] [Q:5 A:0 R:0 HW:0 E:0% U:0.00/m] I figure this would save me an hour or two of hacking things together, so I'd be happy to "donate" 2btc for this feature  Also, with --verbose on, and logging stderr to a logfile, I'm getting a lot of: [2011-08-18 02:20:49] X-Roll-Ntime found Does this log entry have a purpose/something I should be looking at? Additionally, the periodic GPU stats could be removed from --verbose, replaced with the above feature - it would keep the log output consistent nicely I believe. -Phil Seems fair enough. It seems a lot of people use the debug mode and just parse that. I can make this ~ the verbose mode. |
|
|
|
I last upgraded to 1.5.3 on the day it was released. It ran stable from that day until today when I stopped it to upgrade to 1.5.6. It lead to a dead GPU within a rather short period of time twice in spite of a cooler environment. In each instance, cgminer would behavie as if it was going to quit wen I hit Q, but then never terminate (defunct/zombified) and I would be unable to start a new SSH session or perform a soft reboot (init 6 wouldn't do anything, so I assume all new processes were locking up), so I had to hard reboot. I switched back to 1.5.3 and I am mining fine. This is on an HD 5830. Any thoughts? Any thing I might do to help debug? This is Fedora 15 with the old JSON library that I have to modify the Makefile to ignore and use the built-in (hasn't been a problem on previous builds).
That is a hardware hang on your GPU from being overworked. Ironically the faster kernel means you have to decrease your overclock or provoke a hang. You'll have to find a new stable lower OC value for this kernel. |
|
|
|
[2011-08-17 17:56:04] Failed to init GPU thread 0
[2011-08-17 17:56:07] OpenCL compiler generated a zero sized binary, may need to reboot!
[2011-08-17 17:56:07] Failed to init GPU thread 1
[2011-08-17 17:56:10] OpenCL compiler generated a zero sized binary, may need to reboot!
[2011-08-17 17:56:10] Failed to init GPU thread 2
[2011-08-17 17:56:13] OpenCL compiler generated a zero sized binary, may need to reboot!
[2011-08-17 17:56:13] Failed to init GPU thread 3
for me 1.5.6 seems to work only on single card machines, i get the same message from 2 diff machines, one is 2x 5870 and one is 2x 5830 any ideas ? P.S. 1.5.5 works just fine I wish I knew what the actual issue is here, BUT what's happening is it's trying to build a program using the opencl compiler and it's being reported as being zero sized. The compiler seems to be screwing something up and I can't seem to debug why and where. However, most people find that starting it up many times over it will eventually work, and from that moment on it works fine.... go figure. Perhaps I should just make it try over and over within the code... |
|
|
|
|
Show Posts
