Latest git is not mining on my machine at all. It is detecting hardware, connecting to pools and just quit. Good I have working exe from previous build  What hardware would that be? 2x usb erupter and 1x BFL 30GH/s directly to mobo. How very odd, I don't think any of the code for those specifically was changed, nor for windows. You sure you're building it ok for your devices if you're building it yourself? |
|
|
|
Latest git is not mining on my machine at all. It is detecting hardware, connecting to pools and just quit. Good I have working exe from previous build What hardware would that be? |
|
|
|
Are nanofurys supported by 3.6.6?
No, none of the developers have one and no one has tried to offer us one or contribute any code for one so there's no sign of there being any support for them forthcoming in cgminer. |
|
|
|
the 3.6.6 versio nseems super buggy
That's a super generalisation without details. |
|
|
|
ckolivas, I think you may be on to something here with the "to" build. It seems to be the best so far, but not stable like the 3.5.1 build.
I had it running for 1 hour 20 mins before a zombie AMU 29 appeared, which in itself is longer than the other tests have managed. However, I checked the logfile and found that the zombie was preceded by LIBUSB_ERROR_TIMEOUTs from AMU 20 and it was followed by repeated LIBUSB_ERROR_TIMEOUTs from AMU 0. Once the errors from AMU 0 start, there appears to be a permanent condition such they never stop.
Thanks. What was the initial timeout error? Did it say whether it was a write or a read? All "write" errors in the whole log - including 10 from AMU 20 at 11:44 (probably a red-herring) then: [2013-10-31 11:46:28] AMU 29 SendWork usb write err:(-4) LIBUSB_ERROR_NO_DEVICE [2013-10-31 11:46:28] AMU29: Comms error (werr=-4 amt=0) [2013-10-31 11:46:28] AMU 29 failure, disabling! [2013-10-31 11:46:28] Thread 29 being disabled -4 really is the system telling us the device has effectively gone. That's quite different to timeouts, and in fact has been in every one of your logs (appreciate you having posted them by the way). I honestly don't know what this means but it's a very different failure to some kind of runaway process that never times out. |
|
|
|
ckolivas, I think you may be on to something here with the "to" build. It seems to be the best so far, but not stable like the 3.5.1 build.
I had it running for 1 hour 20 mins before a zombie AMU 29 appeared, which in itself is longer than the other tests have managed. However, I checked the logfile and found that the zombie was preceded by LIBUSB_ERROR_TIMEOUTs from AMU 20 and it was followed by repeated LIBUSB_ERROR_TIMEOUTs from AMU 0. Once the errors from AMU 0 start, there appears to be a permanent condition such they never stop.
Thanks. What was the initial timeout error? Did it say whether it was a write or a read? |
|
|
|
Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose. I'd get errors left and right on my AMD box with anything after 3.3.4, I think... until 3.6.4. So what fixed problems for me caused problems for others. Since yours got better moving to 3.6.x, can you also test to see if the -to binary does not make things worse for you please? http://ck.kolivas.org/apps/cgminer/temp/cgminer-to.exeThanks! |
|
|
|
For those people having trouble connecting to *some* pools out there (the ones using round robin for DNS such as eligius), I have built a binary incorporating some upcoming changes to cgminer that hopefully should help: http://ck.kolivas.org/apps/cgminer/temp/cgminer(For advanced users only since you have to copy this to your knc device under ssh as per my first binary upload). |
|
|
|
I posted this in the hashfast thread: My hashfast contact and I have been working on the cgminer driver for a while for this protocol, and fortunately since they contacted me early, their final protocol is quite different to what they originally had in mind. I'm very pleased with the design overall, and the cgminer driver for it we've been working on will be pushed to a public repository tomorrow.
To be fair, cointerra had contacted me effectively even earlier in their development process than hashfast, so I'll have had even more input into their final protocol and driver design. |
|
|
|
|
Codedrop of hashfast driver into master cgminer git.
|
|
|
|
ckolivasit is normal for 3.6.6-1? in other versions there is no such This is not a solo. So on any script coins. Not only at me. 3.6.4 works fine  Yeah I probably screwed that up for $scryptcoins when I fixed it for bitcoin. |
|
|
|
I *could* try some intermediate versions between 3.3.1 and 3.6.4 if thay are still available, and if it would help?
If there's a specific version update that causes it, it narrows down the possible causes of post 3.3.1 breakage (though I've rewritten everything I could think of in the meantime so could have some other issue now). |
|
|
|
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? |
|
|
|
|
Yeah zlp were done blind. Seems they're broken so no one else should bother testing them.
|
|
|
|
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.exehttp://ck.kolivas.org/apps/cgminer/temp/cgminer-zlpcps10.exeThe 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  |
|
|
|
|
Show Posts
