Puzzling that chop1 was almost error-free for me (if you don't count the festive LED displays) but fairly poor for jmc1517. Messy stuff.
"rs" is looking good for me, 10 minutes in.
Edit: Oops, AMU8 went zombie, 15 minutes in.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 191. (Read 5805531 times)
October 30, 2013, 08:23:58 AM
October 30, 2013, 08:17:40 AM
So I'm back to mining on 3.3.1 after completing the above tests and everything is running perfectly. I would stick with 3.3.1 except that it doesn't always show all the devices on startup, and doesn't handle hot-plugging as well as the later builds. Perhaps we can't have everything?!
Why the fuck not goddamnit 
And why 3.3.1? Did it break precisely at 3.3.2?
October 30, 2013, 08:16:06 AM
If you didn't have enough to test, here's 2 more.
http://ck.kolivas.org/apps/cgminer/temp/cgminer-zlpcps10.exe
EDIT: Broken, don't bother.
OK, so a bit more testing done this morning on the following 3 builds, using 34 Erupters on 3 Anker 10-port hubs plus a 4-port Silvercrest oldie, all hubs powered off/on before each test, results as follows:
cgminer-cwa16: The first solid LED on an AMU came on after about 30 minutes. No zombie reported - just the
hash count slowly declining to zero. Loads of timeout errors scrolling up the console.
cgminer-chop1: First zombie after about 22 minutes and the usual timeout errors from others.
cgminer-rs: Three zombies within 10-14 minutes and other AMUs with zero hash count. Loads of timeouts.
Logfiles (without --debug) here if required:
https://dl.dropboxusercontent.com/u/44240170/logfile-cwa16.txt
https://dl.dropboxusercontent.com/u/44240170/logfile-chop1.txt
https://dl.dropboxusercontent.com/u/44240170/logfile-rs.txt
So I'm back to mining on 3.3.1 after completing the above tests and everything is running perfectly. I would stick with 3.3.1 except that it doesn't always show all the devices on startup, and doesn't handle hot-plugging as well as the later builds. Perhaps we can't have everything?!
October 30, 2013, 08:06:16 AM
Yeah zlp were done blind. Seems they're broken so no one else should bother testing them.
Whew - I was afraid I'd done something goofy - I was in a big rush at the time. No problem, where were we?... I'll stop the chop1 test now. It ran for about 10 hours and has (only) one zombie.
I'll test the "rs" version shortly.
October 30, 2013, 07:56:52 AM
You still have: WTF RDLOCK ERROR ON LOCK! in the binary.
Here's one for you:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe
October 30, 2013, 03:32:41 AM
You still have: WTF RDLOCK ERROR ON LOCK! in the binary.
October 30, 2013, 01:04:18 AM
Next AMU windows test binary:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-rs.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-rs.exe
October 29, 2013, 10:36:39 PM
Yeah zlp were done blind. Seems they're broken so no one else should bother testing them.
October 29, 2013, 09:57:19 PM
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.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.
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.
OK. I'll set chop1 aside and try zlp next. Chop1 has gone almost 4 hours without failure, but it's lively to watch. I'll probably leave zlp unattended for the next 9 hours or so if it gets off to a good start.
Edit: Yikes - zlp is off to a very bad start. Tons of error messages, but they scroll quickly. Let's see - AMU0 Timeout sendwork took (about 2 seconds) but was (about 1 second) sendwork USB write error 7 LIBUSB_ERR_TIMEOUT - that's about all I can grab while it scrolls. It's all intermingled with "accepted" messages from the BAL unit. I've left it running for now in the hope that it might stabilize.
Edit: Did a quick test of zlpcps10 and got similar errors to zlp. I was in too much of a hurry though and didn't disconnect the hubs between tests, so I should test it again. I'm out of time right now though, so I have set it back to running chop1. I'll check the thread in about 10 hours.
October 29, 2013, 09:49:04 PM
If its flashing than coming back on , did you notice if it said "new block detected , Pool requests restart". At least when I was using eclipseMC that would completely stop mining and then start back up for each block. Another pool does that but it doesn't restart . Eclipse found so many blocks at one point that I had to switch to another pool or just unplug my eroupters.
That's my easy excuse for the calming fans and lights.
That's my easy excuse for the calming fans and lights.
As far as I can tell there has been only one message since startup (in the console window) for this run, and that was when Icarus hotplugged the last AMU. Each of these tests seems to have different patterns at startup. Sometimes they are all quick, sometimes there's a pause after a few, and sometimes it thinks it has to hotplug the last one or two. Anyway - no pool-requested restarts on this run that I know of. I have seen that kind of message in the past though. I've been using Slush for most of these tests, and stats there for my miners look pretty normal, within the usual error factors, I think.
Anyway, thanks for the tip and I'll keep my eyes open for pool restart messages. Another tester has been logging his tests (see upthread), so that might help pin things down too.
October 29, 2013, 09:25:28 PM
If its flashing than coming back on , did you notice if it said "new block detected , Pool requests restart". At least when I was using eclipseMC that would completely stop mining and then start back up for each block. Another pool does that but it doesn't restart . Eclipse found so many blocks at one point that I had to switch to another pool or just unplug my eroupters.
That's my easy excuse for the calming fans and lights.
That's my easy excuse for the calming fans and lights.
October 29, 2013, 09:19:08 PM
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.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.
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.
October 29, 2013, 09:17:10 PM
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.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.
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.
October 29, 2013, 08:34:55 PM
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.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.
If you didn't have enough to test, here's 2 more.
http://ck.kolivas.org/apps/cgminer/temp/cgminer-zlpcps10.exe
EDIT: Broken, don't bother.
October 29, 2013, 07:30:24 PM
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:
Looking at the config file saved by the KnC WebUI, I see this line:
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?
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:
Quote
"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?
October 29, 2013, 07:20:04 PM
Thank You ckolivas Some of the guys are running CGMiner in Linux and mining away. I'm running Win7 (64bit). Jesse11
Some of the guys are running CGMiner in Linux and mining away. I'm running Win7 (64bit). Jesse11 October 29, 2013, 07:15:23 PM
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?
October 29, 2013, 05:43:44 PM
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.
October 29, 2013, 05:16:40 PM
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)I tried: -0 http://stratum.btcguild.com:3333 -u username - p x -- usb KLN: 3 --enable-klondike16
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
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?
October 29, 2013, 04:56:52 PM
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.
Jump to: