OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[-ck]

Chop8 test results: elapsed time 9.5 hours, mainly unattended, led to three failures. Two are zombies and the third reports a zero hash rate and has the LED on solidly. The former "suspect" AMU was not one of the three. Neither was its former location on the hub.

I'll test chop10 shortly.

Hrm..

I have a new lead...

http://ck.kolivas.org/apps/cgminer/temp/cgminer-pps32.exe

[jmc1517]

So I have tested the 3 builds below, and out of the three, chop10 seems the most promising.  I stop testing usually as soon as a zombie appears, since I can run version 3.3.1 for days on end without problems.

cgminer-cwa8
One AMU LED came on after 30 seconds into the test.  It stayed on for about 2-3 seconds then went off again. I don't know the AMU number, but no messages appeared on screen and it seems to have recovered OK. No zombie. However, the first zombie appeared after 3 minutes (AMU33), followed by loads of LIBUSB_ERROR_TIMEOUTs from AMU0.  Curious as to why AMU0 should be the one to give continuous timeouts when it seems to be working OK?

cgminer-chop8
A zombie (AMU24) appeared after 11 minutes,  followed by an error timeout from AMU23 then loads of repeated timeouts from AMU0.

cgminer-chop10
First zombie after an hour and 10 minutes:
 AMU 13:                 | ZOMBIE/332.2Mh/s | A:330 R:0 HW:10 WU: 4.4/m
Followed by continuous timeouts from AMU 0.

Instead of stopping the test, I unplugged the zombie AMU (AMU13?) and observed that timeouts from AMU 0 stopped, then I replugged (AMU13?) in at 11:33 and it started working as AMU34.  Returning later, there were 2 zombies reported, but one of those was in the same position as AMU34 - which was AMU13 - and no mention of AMU34 in the table. Is this to be expected, or something strange? Full info in logfile.

Logfiles here (without --debug) if required:
 https://dl.dropboxusercontent.com/u/44240170/logfile-cwa8.txt
 https://dl.dropboxusercontent.com/u/44240170/logfile-chop8.txt
 https://dl.dropboxusercontent.com/u/44240170/logfile-chop10.txt

Ah, now I see we have another candidate!  On to try cgminer-pps32 next... 

[jmc1517]

Two test runs with cgminer-pps32:

1st run: Within 10 minutes, the LED for AMU27 came on steadily and the hash rate slowly decreased down towards zero, then jumped up and started decreasing again. The LED was lit all the time.  Soon after, a different AMU (AMU16) was reported as zombie. Test stopped.

Restarted the 3 10-port hubs (off/on). Didn't touch the 4-port hub as there were no errors relating to it (normally I restart them all just to be sure).

2nd run: Only 30 devices initially detected on-screen, but all 34 devices initially observed "flashing" processing shares.  Missing devices detected one-by-one and appeared in the on-screen list, but the process took probably a minute or so?  However, the first zombie appeared after about 5 minutes, so I stopped the test.

Logfiles (without --debug):
 https://dl.dropboxusercontent.com/u/44240170/logfile-pps32-1.txt
 https://dl.dropboxusercontent.com/u/44240170/logfile-pps32-2.txt

So, "chop10" still looks the most promising from an end-user point of view, but for mining stability it doesn't appear to match 3.3.1, unless the test was just very unlucky of course.

[aigeezer]

So, "chop10" still looks the most promising from an end-user point of view

Same here, so far - no anomalies after almost two hours. I haven't tried pps32 yet.

Edit: Spoke too soon, AMU7 went zombie about 3 hours in. I'll switch to pps32 now.

Edit: pps32 failed early. I watched an LED stay on and saw the hashrate for AMU12 creep down to zero after only about 8 minutes. Replugged it and it got reassigned to AMU13 and the hashrate crept back up. The run continues.

Edit: AMU10 went zombie under pps32 after about 1.5 hours. Replugged OK and it got reassigned to AMU14.

Edit: After 3.3 hours total (unattended for a while) I found AMU9 had gone zombie and AMU7 had gone to zero. I'll keep the run going.

[jesse11]

Any update for the settings in cgminer for Klondike K16 mining unit? Some of the guys have got them running in Ubuntu but I'm running Win7. I've tried yet I'm missing something.
I tried: -0 http://stratum.btcguild.com:3333 -u username - p x -- usb KLN: 3 --enable-klondike16

Here's an updated build (untested) containing the latest klondike support  build into the windows binary (do not use --enable-klondike16, that's a BUILD option, not a RUN option)

http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe

No go, I get;  WTF RDLOCK ERROR ON LOCK!  errno=0 in driver -- klondike.c klondike_get_replies<> :971

[rav3n_pl]

log.wtf: What a Terrible Failure: Report an exception that should never happen.
http://developer.android.com/reference/android/util/Log.html#wtf%28java.lang.String,%20java.lang.Throwable%29

[jesse11]

Yep, The error will always be logged at level ASSERT with the call stack.

[-ck]

Any update for the settings in cgminer for Klondike K16 mining unit? Some of the guys have got them running in Ubuntu but I'm running Win7. I've tried yet I'm missing something.
I tried: -0 http://stratum.btcguild.com:3333 -u username - p x -- usb KLN: 3 --enable-klondike16

Here's an updated build (untested) containing the latest klondike support  build into the windows binary (do not use --enable-klondike16, that's a BUILD option, not a RUN option)

http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe

No go, I get;  WTF RDLOCK ERROR ON LOCK!  errno=0 in driver -- klondike.c klondike_get_replies<> :971

Try redownloading, kano fixed that seconds after the first time I uploaded it. The WTF is something I put there myself.

[techman05]

Sorry if you'd like to have the good news to a minimum but I just got 2 more eroupters and other than having to unplug and replug in they were recognized they were recognized without a full pc restart after it installing drivers with the new zadig. I was so happy I didn't have to unplug every device to get it to start seeing the new devices.

I don't expect to test the driver unplug method again unless I find a great deal on a hub to expand my small herd of eroupters but I just thought I'd mention I noticed it with 3.6.6 played nicer than previous version with zadig and WinUSB.

[-ck]

Sorry if you'd like to have the good news to a minimum but I just got 2 more eroupters and other than having to unplug and replug in they were recognized they were recognized without a full pc restart after it installing drivers with the new zadig. I was so happy I didn't have to unplug every device to get it to start seeing the new devices.

I don't expect to test the driver unplug method again unless I find a great deal on a hub to expand my small herd of eroupters but I just thought I'd mention I noticed it with 3.6.6 played nicer than previous version with zadig and WinUSB.

LOL, sweet.

[-ck]

So, "chop10" still looks the most promising from an end-user point of view

Same here, so far - no anomalies after almost two hours. I haven't tried pps32 yet.

Edit: Spoke too soon, AMU7 went zombie about 3 hours in. I'll switch to pps32 now.

Edit: pps32 failed early. I watched an LED stay on and saw the hashrate for AMU12 creep down to zero after only about 8 minutes. Replugged it and it got reassigned to AMU13 and the hashrate crept back up. The run continues.

Edit: AMU10 went zombie under pps32 after about 1.5 hours. Replugged OK and it got reassigned to AMU14.

Edit: After 3.3 hours total (unattended for a while) I found AMU9 had gone zombie and AMU7 had gone to zero. I'll keep the run going.

Nice work guys.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-cwa16.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-chop1.exe

[techman05]

Can I post quick thought? Do you know it seems you have the threads preset where they go? I wanted to see what cores I was using for cgminer and when I went to set affinity where I think they are set it said "Access Denied" and something much have crashed for a second since when I click o.k it saw the please wait logo spinning. Its probably since I run cgminer as admin but I thought I'd share it since its the first time I've knowingly seen I couldn't set cpu usage for a program.

[jesse11]

Any update for the settings in cgminer for Klondike K16 mining unit? Some of the guys have got them running in Ubuntu but I'm running Win7. I've tried yet I'm missing something.
I tried: -0 http://stratum.btcguild.com:3333 -u username - p x -- usb KLN: 3 --enable-klondike16

Here's an updated build (untested) containing the latest klondike support  build into the windows binary (do not use --enable-klondike16, that's a BUILD option, not a RUN option)

http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe

No go, I get;  WTF RDLOCK ERROR ON LOCK!  errno=0 in driver -- klondike.c klondike_get_replies<> :971

Try redownloading, kano fixed that seconds after the first time I uploaded it. The WTF is something I put there myself.

ReDownLoading 3 times. Still WTF RDLOCK ERROR ON LOCK!  Do you have a new link for http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe?

[aigeezer]

http://ck.kolivas.org/apps/cgminer/temp/cgminer-cwa16.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-chop1.exe

Cwa16 test started, fine so far. The pps32 test went a few more hours with occasional zombies restarted. I figured the details weren't remarkable.

Zombie on AMU12, 20 minutes in to the cwa16 text, followed quickly by four more. Arguably the least promising of the recent candidates. I'll switch to chop1 now.

Edit: the chop1 test is interesting. No failures yet, one hour in. From time to time random LEDs put on a festive but somewhat scary display, for many seconds, often four or five at a time.
Also, the hash rate reported soars randomly from time to time, no apparent correlation with the LED lights. An AMU will show well over 400, sometimes well over 500 Mh/s, then slowly drift back to a normal 333 or so. I don't recall seeing this behavior before, but perhaps I've just missed it. The test continues.

 

[-ck]

ReDownLoading 3 times. Still WTF RDLOCK ERROR ON LOCK!  Do you have a new link for http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe?

Ah this is a different issue. Will notify you when a new binary is available.

[jesse11]

Thank You ckolivas     Some of the guys are running CGMiner in Linux and mining away. I'm running Win7 (64bit).   Jesse11

[xyzzy099]

Hi Mr. Ckolivas.  I have a KnC Saturn with the new 0.98 firmware which includes your new CGMiner for KnC.  Everytime I restart CGMiner via the web interface, and then quickly start a screen session so I can see the startup, I see the warning "Error in configuration file, partially loaded.".  If I start cgminer by hand with '-T -D', I see this error:

Code:

[2013-10-29 23:20:43] Invalid config option --api-network: Invalid value

Looking at the config file saved by the KnC WebUI, I see this line:

"api-network": false

as the last line in the file, before the closing brace.  Looks ok to me...  Any idea why I am getting an error here consistently?

[-ck]

Edit: the chop1 test is interesting. No failures yet, one hour in. From time to time random LEDs put on a festive but somewhat scary display, for many seconds, often four or five at a time.
Also, the hash rate reported soars randomly from time to time, no apparent correlation with the LED lights. An AMU will show well over 400, sometimes well over 500 Mh/s, then slowly drift back to a normal 333 or so. I don't recall seeing this behavior before, but perhaps I've just missed it. The test continues.

Thanks.

If you didn't have enough to test, here's 2 more.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-zlp.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-zlpcps10.exe
EDIT: Broken, don't bother.

[aigeezer]

Edit: the chop1 test is interesting. No failures yet, one hour in. From time to time random LEDs put on a festive but somewhat scary display, for many seconds, often four or five at a time.
Also, the hash rate reported soars randomly from time to time, no apparent correlation with the LED lights. An AMU will show well over 400, sometimes well over 500 Mh/s, then slowly drift back to a normal 333 or so. I don't recall seeing this behavior before, but perhaps I've just missed it. The test continues.

Thanks.

If you didn't have enough to test, here's 2 more.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-zlp.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-zlpcps10.exe

The chop1 test is 3+ hours old and no failures yet. It just did something dramatic though - all 13 AMU LEDs came on at about the same time and the BAL fan throttled down and its hash rate dropped somewhat. A few seconds later everything was back to normal. No smoke, no flames, no melted solder - I'll stay with it a while unless it fails.       

[-ck]

Edit: the chop1 test is interesting. No failures yet, one hour in. From time to time random LEDs put on a festive but somewhat scary display, for many seconds, often four or five at a time.
Also, the hash rate reported soars randomly from time to time, no apparent correlation with the LED lights. An AMU will show well over 400, sometimes well over 500 Mh/s, then slowly drift back to a normal 333 or so. I don't recall seeing this behavior before, but perhaps I've just missed it. The test continues.

Thanks.

If you didn't have enough to test, here's 2 more.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-zlp.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-zlpcps10.exe

The chop1 test is 3+ hours old and no failures yet. It just did something dramatic though - all 13 AMU LEDs came on at about the same time and the BAL fan throttled down and its hash rate dropped somewhat. A few seconds later everything was back to normal. No smoke, no flames, no melted solder - I'll stay with it a while unless it fails.       

Heh odd. The ZLP is likely a very real fix for an issue though, and hopefully it's a related issue to what's biting you and indirectly fixed with the chop1 executable. It still doesn't sound like normal behaviour even if it hasn't outright failed, though bear in mind a couple of pools are under ddos yet again so that might be related