I've noticed something strange about the Windows version of cgminer. With only GPU mining enabled, there are 6 instances of the program running; 5 of which are using 1,216K of memory and 0% CPU. Is there a purpose for these threads or is your miner having accidental child processes?
They are most definitely there for a purpose. 2 per GPU, Workio thread, staging thread, longpoll thread, watchdog thread, gpu restart thread, cpu restart thread, and then there's a thread spawned (and then killed) for every getwork request and every submit work. 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 804. (Read 5805728 times)
August 17, 2011, 04:49:08 AM
August 17, 2011, 04:45:36 AM
@ck: Is anything like Phoenix's -s planned?
ie
-s SOCKETNAME, --socketname=SOCKETNAME
full path to file for outputting current status.
That would be so delightfully cool... and useful.
ie
-s SOCKETNAME, --socketname=SOCKETNAME
full path to file for outputting current status.
That would be so delightfully cool... and useful.
August 17, 2011, 04:33:08 AM
You know, this actually could be a problem with Linuxcoin. It is still a beta after all. You may want to try using another Linux distro on your USB and see if the problem persists. If it doesn't, we may need to take a look at the repository of Linuxcoin and see which dependency is causing the issue before a work-around can be cooked-up.
Uhm,
I issued a
Code:
ldd cgminer
on my system and this is what I get, can this be of any help in figuring out what could be wrong?
Code:
linux-vdso.so.1 => (0x00007fffd67ff000)
libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f67745aa000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f677438e000)
libOpenCL.so.1 => /opt/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/libOpenCL.so.1 (0x00007f6774188000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00007f6773f41000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6773bbe000)
libidn.so.11 => /usr/lib/libidn.so.11 (0x00007f677398a000)
libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007f6773765000)
liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00007f6773557000)
libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x00007f6773308000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6773100000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007f6772ec1000)
libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f6772c6e000)
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f67728a8000)
librtmp.so.0 => /usr/lib/librtmp.so.0 (0x00007f6772690000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f6772478000)
libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f67721ce000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6774821000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6771fca000)
libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f6771d50000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f6771b3a000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00007f677191f000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007f6771652000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007f6771429000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x00007f6771226000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007f677101d000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f6770e1b000)
libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007f6770c0a000)
libgpg-error.so.0 => /lib/libgpg-error.so.0 (0x00007f6770a07000)
spiccioli
August 17, 2011, 04:18:07 AM
The new kernel works things -even harder- so if you were getting sick GPUs before, you still will now. The difference is it should recover by itself. If you get sick GPUs all the time, I suggest dropping the intensity down till you find where they stop being sick.
August 17, 2011, 03:50:00 AM
ckolivas,
sorry to report that on my system 1.5.6 declares my GPUs (a 5850 and a 5870) sick after a few minutes of work just as 1.5.3 did.
I'm on a linuxcoin 0.2a system booting from a USB key (with persistence), I don't think I have hardware problems since different miners work without problems.
best regards.
spiccioli.
You know, this actually could be a problem with Linuxcoin. It is still a beta after all. You may want to try using another Linux distro on your USB and see if the problem persists. If it doesn't, we may need to take a look at the repository of Linuxcoin and see which dependency is causing the issue before a work-around can be cooked-up. sorry to report that on my system 1.5.6 declares my GPUs (a 5850 and a 5870) sick after a few minutes of work just as 1.5.3 did.
I'm on a linuxcoin 0.2a system booting from a USB key (with persistence), I don't think I have hardware problems since different miners work without problems.
best regards.
spiccioli.
August 17, 2011, 03:27:37 AM
ckolivas,
sorry to report that on my system 1.5.6 declares my GPUs (a 5850 and a 5870) sick after a few minutes of work just as 1.5.3 did.
I'm on a linuxcoin 0.2a system booting from a USB key (with persistence), I don't think I have hardware problems since different miners work without problems.
best regards.
spiccioli.
sorry to report that on my system 1.5.6 declares my GPUs (a 5850 and a 5870) sick after a few minutes of work just as 1.5.3 did.
I'm on a linuxcoin 0.2a system booting from a USB key (with persistence), I don't think I have hardware problems since different miners work without problems.
best regards.
spiccioli.
August 17, 2011, 03:12:02 AM
Hi,
diff old_main.c main.c
3795c3795
< "longpoll failed, sleeping for 30s");
---
> "longpoll failed for %s, sleeping for 30s",lp_url);
Best
/GoK
Good idea. Though I might just put the pool number rather than the whole URL because the URL can be quite long leading to a very long log message. ?diff old_main.c main.c
3795c3795
< "longpoll failed, sleeping for 30s");
---
> "longpoll failed for %s, sleeping for 30s",lp_url);
Best
/GoK
That works just fine,
Thanx
/GoK
August 17, 2011, 03:08:13 AM
I've noticed something strange about the Windows version of cgminer. With only GPU mining enabled, there are 6 instances of the program running; 5 of which are using 1,216K of memory and 0% CPU. Is there a purpose for these threads or is your miner having accidental child processes?
August 17, 2011, 02:35:32 AM
Too good to pass up a new release even with only 2 real changes.
Version 1.5.6 (you all know where by now - links in first post).
Executive summary: New faster phatk kernel (2.2) courtesy of phateus porting it (thanks!) and with my own custom modifications on top. Fixed multiple pool longpoll management.
From all of us... *Hugs* Version 1.5.6 (you all know where by now - links in first post).
Executive summary: New faster phatk kernel (2.2) courtesy of phateus porting it (thanks!) and with my own custom modifications on top. Fixed multiple pool longpoll management.
August 17, 2011, 02:18:02 AM
Too good to pass up a new release even with only 2 real changes.
Version 1.5.6 (you all know where by now - links in first post).
Executive summary: New faster phatk kernel (2.2) courtesy of phateus porting it (thanks!) and with my own custom modifications on top. Fixed multiple pool longpoll management.
Version 1.5.6 (you all know where by now - links in first post).
Executive summary: New faster phatk kernel (2.2) courtesy of phateus porting it (thanks!) and with my own custom modifications on top. Fixed multiple pool longpoll management.
August 17, 2011, 01:46:36 AM
New phatk and poclbm kernels in git tree for those who've been waiting for them.
Hopefully new release just around the corner with that
Hopefully new release just around the corner with that
August 17, 2011, 01:15:13 AM
Yes indeed, that's what I've spent weeks working on to get right. To restart it if it can only. The 5 minutes was a nominal choice based on the theory that if it gets sick, giving it a few minutes to cool down will make it more likely to respond. Note that if it gets sick a LOT, you may benefit from decreasing the intensity and sacrificing a few MH just to get a more stable throughput (eg -I 7 instead of 
.
.Only happened twice in 4-5 hours, so I think I'm ok. It's 5 minutes then... I need patience... or a command line switch?
Edit: confirmed, it restarts after 5 minutes. An option would be nice - my GPUs cool down way faster than that, and I think that's the case with most miners, most of them have extra fans and cooling.
August 17, 2011, 01:12:41 AM
I might have detected a memory leak in 1.5.5. After ~8 hours of work, cgminer got oom-killed. I restarted the process and I'm taking ps snapshots every 10 minutes to see if I'm right. I'll be back .
. August 17, 2011, 12:52:29 AM
Apologize if it was already addressed or noted somewhere but I cannot seem to find it. Is it possible to set Intensity per GPU? If not, would that be something difficult to add? I like being able to manage each GPU individually and in my case, one of my GPUs isn't always a dedicated miner while the other is.
Unfortunately there is not a way to do that at the moment. In the readme you'll see it recommends running 2 instances of cgminer selecting which GPUs to use. Use one instance in dynamic mode and the other with a set intensity. 
August 17, 2011, 12:40:34 AM
Apologize if it was already addressed or noted somewhere but I cannot seem to find it. Is it possible to set Intensity per GPU? If not, would that be something difficult to add? I like being able to manage each GPU individually and in my case, one of my GPUs isn't always a dedicated miner while the other is.
August 16, 2011, 07:01:04 PM
August 16, 2011, 06:55:36 PM
Oh, it is not really working for me. I am still having difficulties with cgminer on Mac mini. It shows 4124 Megahash/s which is not realistic on my Mac mini. (DiableMiner shows me 48350 khash/sec)
During 17 minutest there were still 0 accepted shares.
During 17 minutest there were still 0 accepted shares.
Code:
localhost:cgminer thomas$ ./cgminer -o http://api2.bitcoin.cz:8332 -u name.name-p password -I 8
[2011-08-17 01:47:41]
Summary of runtime statistics:
[2011-08-17 01:47:41] Started at [2011-08-17 01:30:37]
[2011-08-17 01:47:41] Runtime: 0 hrs : 17 mins : 3 secs
[2011-08-17 01:47:41] Average hashrate: 4124.6 Megahash/s
[2011-08-17 01:47:41] Queued work requests: 11733
[2011-08-17 01:47:41] Share submissions: 0
[2011-08-17 01:47:41] Accepted shares: 0
[2011-08-17 01:47:41] Rejected shares: 0
[2011-08-17 01:47:41] Hardware errors: 0
[2011-08-17 01:47:41] Efficiency (accepted / queued): 0%
[2011-08-17 01:47:41] Utility (accepted shares / min): 0.00/min
[2011-08-17 01:47:41] Discarded work due to new blocks: 0
[2011-08-17 01:47:41] Stale submissions discarded due to new blocks: 0
[2011-08-17 01:47:41] Unable to get work from server occasions: 0
[2011-08-17 01:47:41] Work items generated locally: 0
[2011-08-17 01:47:41] Submitting work remotely delay occasions: 0
[2011-08-17 01:47:41] New blocks detected on network: 19
[2011-08-17 01:47:41] Summary of per device statistics:
[2011-08-17 01:47:41] GPU 0: [4394.3 / 4124.6 Mh/s] [Q:11732 A:0 R:0 HW:0 E:0% U:0.00/m]
August 16, 2011, 06:07:17 PM
./configure works fine, but
make for cgminer 1.5.5 fails now with the following error on Mac mini Lion 10.7:
make for cgminer 1.5.5 fails now with the following error on Mac mini Lion 10.7:
Code:
ld: warning: ignoring file x86_64/libx8664.a, file was built for archive which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"_CalcSha256_x64", referenced from:
_scanhash_sse2_64 in cgminer-sha256_sse2_amd64.o
"_CalcSha256_x64_sse4", referenced from:
_scanhash_sse4_64 in cgminer-sha256_sse4_amd64.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
After uninstalling yasm (with sudo port uninstall yasm) it compiles and runs fine.
August 16, 2011, 05:05:15 PM
./configure works fine, but
make for cgminer 1.5.5 fails now with the following error on Mac mini Lion 10.7:
make for cgminer 1.5.5 fails now with the following error on Mac mini Lion 10.7:
Code:
ld: warning: ignoring file x86_64/libx8664.a, file was built for archive which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"_CalcSha256_x64", referenced from:
_scanhash_sse2_64 in cgminer-sha256_sse2_amd64.o
"_CalcSha256_x64_sse4", referenced from:
_scanhash_sse4_64 in cgminer-sha256_sse4_amd64.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
August 16, 2011, 04:48:34 PM
Do 'SICK' GPU's ever get restarted? Sometimes I get 'Thread 3 idle for more than 60 seconds, GPU 1 declared SICK!' and mining stops on that GPU. If I restart it manually, work resumes just fine, so I guess it cgminer should try to restart the GPU automagically? I waited 3 minutes and the GPU was not restarted, maybe there is a bigger timeout?
Edit: When it gets marked as DEAD, it does get restarted immediately.
Yes indeed, that's what I've spent weeks working on to get right. To restart it if it can only. The 5 minutes was a nominal choice based on the theory that if it gets sick, giving it a few minutes to cool down will make it more likely to respond. Note that if it gets sick a LOT, you may benefit from decreasing the intensity and sacrificing a few MH just to get a more stable throughput (eg -I 7 instead of Edit: When it gets marked as DEAD, it does get restarted immediately.
. Jump to: