|
Minor heads up, there is a newer version of zadig, and I have uploaded it to my website, BUT it contains the same version of the WinUSB driver so it will not change the performance or the behaviour of the drivers once they're installed/assigned.
|
|
|
|
what does higher resolution timeouts mean? Does that mean that cgminer has more time to work itself out if something goes wrong with a device hardware or in cgminer software?
Thanks
Whenever we wait for something in code we tell it to sleep. By default in windows, the sleep time can be accurate to only +/-15ms best case scenario (and is often worse). This may or may not be relevant depending on how critical the timing is on the device. With the experimental changes I've been able to bring it down to +/-0.1μs. Also because there are less layers of code between cgminer and the operating system now, there are less potential points of failure in the code. |
|
|
|
 why doesnt cgminer support asicminer blades? Blades have their own inbuilt ancient mining software and there is no other way to mine on them. All they do is support getwork protocol to a pool/server. If you're talking about cgminer not pretending to be pool software supporting an ancient outdated mining protocol, you're correct, it doesn't. |
|
|
|
To the various windows victims valued testers out there, I have uploaded new experimental binaries that now use windows' own low level clocks and timers to support higher resolution timeouts and hopefully be more reliable than using mingw's wrappers. I also found a bug in the windows code while working on these. For people with timeout issues on windows, please grab one of the exes from this directory and put it into your current cgminer directory: http://ck.kolivas.org/apps/cgminer/temp/ |
|
|
|
More 3.6.4 feedback:
I moved all my USB erupters to another machine. I found cgminer doesn't see any of those plugged into my blue USB 3.0 ports. This is the same experience I had with my laptop. They work fine on the non blue ports. I'm also getting problems with devices zombifying, and the AMU write errors. I did not see any of these errors on the old PC, so it seems once again this is hardware specific. Last time it was AMU 7 that zombified.
M
Thanks M. It seems the massive rewrite I did to fix random timeouts fixed something intrinsic in libusb's own timeouts, but USB 3 slot vs USB1.1 device related issues are different again. I do know that the WinUSB driver itself is not complete with USB3 support and some hardware the devices won't even show up, so there is still hope. I will keep chipping away at whatever other internals I can on cgminer and hopefully newer versions of WinUSB come out that get better (the version on my site bundled with zadig is still the latest version). |
|
|
|
|
...it is always edited with the current version.
|
|
|
|
Still getting the error below with 3.6.4:
[2013-10-21 20:26:13] BAL0: GetResults failed no data returned (err=0 amt=0)
Using USB 2.0 ports directly on the motherboard, restarting CGMINER seems to fix the issue. Tried different USB ports, same issue. Can happen 20 minuter or hours after CGMINER.
It's possible you're having a hardware issue that only shows up after it's been under load for a while. I had this sort of failure with a bad power brick on a single. |
|
|
|
Agreed, sorry, I went in a 'big kid who lost his lolly' crusade to OffTopicLand.
I also apologise for being a TAUC towards kano and ck - there's no need for it, even though I disagree with their choice of USB drivers, they're still producing one of the top-two mining programs, without which BTC wouldn't be where it is now.
I hope you accept my apologies.
Graciously accepted. Humility is a priceless quality, and exceptionally rare on these forums. Now back to the important business of mining... Moving forward, we've been trying to get manufacturers to take the idea of work restart a step beyond the current notion of throw all work out and start again and have at least 2 different levels of restart. One for "updated work" to throw out queued work that's not been started on, and one for "block change" which stops all current work and throws out all queued work. As ASIC manufacturers so far have only been interested in getting hardware out ASAP, it's clear these issues have not remotely concerned them, but we see encouraging signs that the next generation of ASICs will be far more professional and raise the bar for what the standard should be. |
|
|
|
Helo CKolivas and Kano,
Do you have any plans to release a KnCMiner version of CGMiner?
Thank you very much for your contribution to Cryptocoin Mining!!!
KFC sent me a saturn unit for development. I am currently swamped with other work but will eventually get around to working on integrating support for it into master cgminer and hopefully improve on the driver too. |
|
|
|
Due to me fat fingering an edit on cron I think if my math is correct it never restarted cgminer with the newest built from git and made it overnight.
That having been said I am not sure that */220 wouldn't ever run the restart script. I intended to put the new version from */30 to */20 for minutes making it restart 3 times an hour. Since that had stopped the hanging before.
I have moved things around and I still do get errors of the IO type. While moving things I noticed no errors with only 4 jalapeno's. As I was adding the next 4 I didn't see IO errors until the third from that set was added. After having all 9 back on I have only noticed a couple of IO errors. Maybe I should spread the proverbial love to a couple of more raspberry pi's.
Upgrading in the past hasn't helped me at all. I get more crashes and more corrupted sd cards. I tried very shortly arch but my Linux command line is lack luster at best so I went back to raspbian. I even tried MinePeon but the image I downloaded was corrupted. I really do hope the newest version won't require as frequent of a restart.
Well that definitely sounds better than it was. The only other thing I've seen suggested is using a good powered USB supply to the RPi. Perhaps a shorter, thicker cable from a USB3 slot if running off a PC, or a well powered hub if not. |
|
|
|
|
If you don't specify stratum+tcp:// cgminer will try a few different ways to connect first. Some pools might not like the multiple attempts to connect so it is always cleaner and faster to specify the stratum+tcp:// prefix.
|
|
|
|
CK , you might have another big bug. My miners lasted after restart with bitminter and then stopped reacting. I closed and restarted and all is running again. Any Idea if tcp protocols are not friendly with cgminer? I have to start taking pictures next time I see it like that. 3.6.4 lasted alot longer than past 3.6's. Can't say I'll play with bit minter too much more. I'm not getting alot of shares and I can't seem to find what difficulty I should be set at for my Gigahashes  and it hasn't yelled at me to tell me I'm not at a difficulty level it likes and otherwise its not cell phone friendly  . cgminer ONLY does tcp, so I think you're confusing your terminology and looking at something totally unrelated. |
|
|
|
The fault lay with the hardware manufacturers, not p2pool, as p2pool was around long before they started making their ASICs. If all the newer hardware follows the same pattern, things will only improve, and old hardware becomes irrelevant very fast in this world anyway.
Agreed, but pool software should be able to adapt to newer hardware - which p2pool does not do. Other pools adapt - that's why they are more successful/bigger. Exactly. I can point my Blades to any other pool, be it one with a getwork interface, or any stratum pool via a stratum proxy, and guess what? It works. ONLY p2pool shit's it's lips when presented an ASICMiner (or KnC it seems). As usual, ck, you're skirting round an issue and making excuses, rather than fixing the issue - amazing as it isn't even YOUR issue this time... I posted some good news about upcoming hardware and p2pool and you shat on it and turned it into an argument against me. Good work. It gets tiring having you go around dissing the effort I put in just because you support a hostile fork. I don't recall personal attacks against you to make you to take sides with such an aggressive stance. You don't like my software and its approach or p2pool, don't use it, but don't expend so much energy putting down other people's hard work. There's a big difference between constructive criticism and just plain bashing. You want to flame? Take it elsewhere, this is the p2pool thread. To forrestv's credit, he made a LOT of changes leading into the ASIC era, like beefing up stratum support, variable difficulty, clamping down on memory leaks and the longer blocks. There is ALWAYS more work to be done when the landscape is changing so fast in the bitcoin mining world, but it's clear the manufacturers till now have not put p2pool on their radar at all. |
|
|
|
|
No, this is the bitcoin forum, which generously has one altcoin subsection. This issue can be fixed easily enough, just watch.
|
|
|
|
|
The fault lay with the hardware manufacturers, not p2pool, as p2pool was around long before they started making their ASICs. If all the newer hardware follows the same pattern, things will only improve, and old hardware becomes irrelevant very fast in this world anyway.
|
|
|
|
|
There is light at the end of the tunnel. Hashfast's ASICs will have a fast longpoll/block change/flush work implementation and it looks like Cointerra's will too.
|
|
|
|
May be just a wierd 2 bugs but I found that if I incorrectly forgot to save my shortcut right it opens to older folder versions I set and saves config there even though I'm opening 3.6.4. My second I found because cgminer doesn't like strange characters and won't open if they are in the config file. I was trying to set up bit minter as an alternative to another pool and since bit minter looks like it uses tcp instead of http they both get printed at front and leave just as" http://tcp://mint.bitminter.com:3333" plus a few starlike characters in between the protocols the first time it saved. Future bug fixes maybe? Um, you do not use tcp by itself anywhere. You're probably thinking of stratum+tcp:// and http:// is implicitly tcp, so your syntax is wrong. So I have to use that whole statement when filling in the address. O.k I'll go change that. Or just leave it out entirely and cgminer will figure out what to do. |
|
|
|
The IO error on the devices only seems to happen on Linux not my windows box. When I moved those units to the raspberry pi it started having issues.
I can't say for sure there isn't a problem with a cable but I can hook it back up to windows 7 tomorrow maybe and try that.
I built the version from the git. I don't so far dare to stop cron from killing it every half hour. I can't watch it constantly and so far my script to start them up at boot isn't working correctly.
I do have a side issue that isn't cgminer directly. I have been plagued by crashes for a while. I haven't in the past seen anything to make me think mining specifically caused it. The most recent crash left me with the following error. I am including the last line of cgminers output and the crash report. Crash was 3.5.1 not newest from git. crashed after 57 minutes of running. 3 more and it would have restarted at the hour.
After that is some unwind kdb info I can type that up if you would like. It seems like there is a kernel error. I got lucky as for a change the monitor was still getting a signal. Usually power management manages to keep the signal off making the crashes far less useful. I don't know that this will help anything.
There's no doubt the USB in the RPi is less reliable than a real PC. Part of the problem is that the network device is actually a USB device low down meaning USB comms are compromised as a result, and it's all on the same bus. Bus 001 Device 004: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. LAN9500 Ethernet 10/100 Adapter / SMSC9512/9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Unfortunately I can't really start digging into kernel code, but I can at least suggest trying a different distro (though I believe I've said that before). I can reliably crash my RPi by just plugging something into the USB slot that draws more power than usual (such as the BF1 stick) without mining even running. Would be interesting to see now that you've built from git whether you get complete failures with transfer errors or just IO errors as a temporary glitch now. |
|
|
|
...I will be working on the kfc driver code.
Mmmmm delicious extra crispy or regular KFC? I only have the special sauce for original recipe. Both CKolivas (CG) and Luke Jr (BFG) have their own dev boxes, they were sent at the same time they were emailed the source code at the beginning of last week.
And much appreciated Bitcoinorama, thanks. I have commented on this in the cgminer thread already. |
|
|
|
+1 Im starting to see a pattern of conceit among hero members. I would rather use BFG modded fw over CG every day this year (with that said I felt like luke-jr was a little conceited too) Thanks you two for the great sw and all - specifically the free factor, but acting egotistical doesn't help your cause at all.
You're free to do what you like. By the way, though, cgminer is my project. Kano is a value contributor but not the maintainer, and while I have complete control over what code to include, I have zero ability to control what he says or does on the forum. Note that in the future, I will be working on the kfc driver code. |
|
|
|
|
Show Posts
