Negative, 3.4.1 was so far the most stable, when upgraded to 3.4.2 problems started, then 3.4.3 problems became worse...
That's a most interesting observation since the only code difference between 3.4.1 and 3.4.2 was code affecting the BFL SC devices. Not sure what to tell ya man, Wasn't talking about any of the other comments, just that the code for erupters and cgminer is identical from 3.4.1 to 3.4.2, making the association one of coincidence. Not saying it didn't happen, just saying whatever it was got worse for you coincidentally. |
|
|
|
Negative, 3.4.1 was so far the most stable, when upgraded to 3.4.2 problems started, then 3.4.3 problems became worse...
That's a most interesting observation since the only code difference between 3.4.1 and 3.4.2 was code affecting the BFL SC devices. |
|
|
|
4-moduled Avalon B3 generated 27 gb of outgoing traffic per 24 hours? can this be true?
Not likely Here are 8 Avalons (6 x 3 + 2 x 4 modules) running: One machine uses about 7 MB / day worth of trafic Thank you for detailed answer. Here's what I've got: 2Gb for just 5h 35m: My Avalon is hosted in the datacenter and they are asking me to pay bills for this gigabytes (total 143 Gb for more than 1 month). Firmware was taken from http://ck.kolivas.org/apps/cgminer/avalon/20130821/Where are you mining? Diff 1 mining with getwork protocol on an ancient pool might do this. |
|
|
|
Just tested version 3.4.3 - this is working like a charm!
Thankyou to put Socks Proxy Feature back to the miner.
Keep up the good work.
You're most welcome. Thanks for testing it and reporting back. |
|
|
|
|
Not the first time someone made a transaction and screwed up, mistakenly sending a very large transaction fee.
|
|
|
|
I am on MacOSX 10.6.8 (Snow Leopard) with the Mac Ports collection installed.
SNIP Only the release tarball will compile on osx. What I'm saying, though, is if you have a 3.4.3 release, it IS using the latest libusb - statically compiled - regardless of who compiled it for you unless they've gone in and hacked the code to dynamically link the library because there is no way for it to use a dynamic library any more. |
|
|
|
anyone else having payout problems? i've at .03, and my threshold is set to .1 but it hasn't sent anything yet.
.03 is not more than .1 ? |
|
|
|
Really?  How about this? Are you able to reproduce this? Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?
Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field. So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found. That's not a bug. If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API. I would like to point out that there is A BUG ASSOCIATED WITH THAT FEATURE.And that is, that as soon as the "Number of accepted Shares" reaches 10 Million, CGMiner crashes/stops working. I mine on an LTC-Pool with high difficulty and I have to restart CGMiner on a regular basis to make sure the miner just doesn't stop working because it has reached 10 Million diff 1 shares again. Is there an "official" way to report bugs or is ckolivas going to read this? I read it. I read all bug reports - that doesn't mean I instantly respond. It was probably coincidence and an unrelated crash since I went to 50 million shares without a problem. Try a debug build. |
|
|
|
New debug executables uploaded.
All done and started, now we just have to play the waiting game. I haven't seen it crash for at least 2-3 days on 3.4.3 Appreciated. That's no problem as no new release is scheduled any time soon unless I find some hotfix bug worth fixing. I'm currently swamped with other work and probably need a small break from regular cgminer coding anyway. |
|
|
|
No worries - I've done this before for you, happy to do it again.
Let me know when you have 3.4.3 ready
New debug executables uploaded. |
|
|
|
Alternately I flashed my JP with CK's code and I think I'm going to stick with it. Same speed as my code tweaks, but with < 1% errors (I was getting 2.5% or so) and several degrees less heat. I think his code turns off cores that are shot (I have several) and clocks up the remaining ones (to compensate).
As a side note, if anyone in the Baltimore/Laurel MD area wants to bring their jally over for a flash I'll do it for free/tips/whatever with my Dragon and atmel. I think ck's code is good, will drop him/her a tip if I can find her btc wallet.
Thanks, but only my avatar pic is female  |
|
|
|
Just tried them on a Mac Mini with Snow Leopard and a single Block Erupter USB, give the USB timeout errors: [2013-09-17 14:00:28] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:30] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:32] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:34] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:36] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:37] Stratum from pool 0 detected new block
[2013-09-17 14:00:38] AMU0: TIMEOUT GetResults took 1998ms but was 100ms Was there ever a version this didn't happen on? If not, we're kinda screwed until a better libusb for osx comes out since this is a libusb bug which is mostly addressed in the linux and windows versions, yet you're compiling against the same libusb version now (which is included statically in the cgminer source tree now). |
|
|
|
Is there anything I can help with?
I do experience that crash where it just says "cgminer has stopped working". A quick reboot and its up again.
Thanks. I'll keep you posted when I upload the latest debug build and I'll get you to follow the instructions on how to get debugging information from it. You can read the instructions and get prepared here, but they're only cgminer 3.4.2 for the moment: http://ck.kolivas.org/apps/cgminer/debug/ |
|
|
|
This thread makes my head hurt. There is so much cognitive bias in the arguments for the devices that I'm dumbfounded.
The alternative is that some people will have to admit they were wrong about buying the gizmos. That's hard, apparently. Indeed. The specific bias in question has a well defined name too: Post purchase rationalisation. |
|
|
|
So... would it be useful to run w/o a backup pool to see if the problem persists? It certainly would not hurt to try. I have yet to upload debug builds of 3.4.3 and will do so later today, but the underlying stratum code has not changed since 3.4.2, it just had added features rather than changing the codebase. |
|
|
|
I'm not sure of the threading level within stratum when on a single pool.
ckolivas will know the answer to that.
All writes are done from one thread. All reads are done from one thread. Therefore there is no chance of there being a race on reads or a race on writes. I very much doubt windows has an issue of writing and reading the same socket at the same time, nor would there be a problem using two different sockets at the same time. Debugging points to something in socket code, possibly on reconnecting or trying to communicate with a backup pool. I keep auditing the code and come up none the wiser, but I will continue to do so, or give up entirely and stop supporting windows (yeah right, 85% of cgminer users are on windows sigh). |
|
|
|
Hmm. Thing is, the stratum code is all done raw now, not using any other libraries precisely because I had problems with libcurl and friends. So the code does raw socket calls which directly use winsock calls. So the problem is either in cgminer or the MS dll.
I hate to be the bearer of bad news, but I doubt it's the winsock dll. A lot of programs use that, and if there was a native problem in there, we'd be getting crashes elsewhere from other apps. Yes a lot use the winsock dll. Note the issue is in mswsock.dll though, and it is actually very rare that applications use raw sockets on windows so I wouldn't say it's quite the same - firefox only recently started using it and lo and behold it's been getting crashes in the same library. Nonetheless, logically my code which is always in heavy development is far more likely to be at fault than an OS provided library (though we've been burnt by that enough already to know it's not impossible). Every attempt so far to get debugging with a full debug build, it always ends up crashing with an overflow in mswsock.dll though, so not sure where to go next... |
|
|
|
|
Hmm. Thing is, the stratum code is all done raw now, not using any other libraries precisely because I had problems with libcurl and friends. So the code does raw socket calls which directly use winsock calls. So the problem is either in cgminer or the MS dll.
|
|
|
|
mwsock.dll ... hmm I wonder how many times that's been reported in here ... and your not running the latest version I have now updated to 3.4.3. I just searched through this thread and didn't seem to find any solutions for fixing the mwsock.dll issue. Any thoughts? Unfortunately we have no solution for a microsoft provided dll crashing. It should not be possible for our software to crash the dll unless there's a bug in the dll. The only suggestions are checking you have the latest dll and there are no virus/trojans that have attached to it. Not that I think the cgminer devs should in any way be responsible for taking this action, but it is possible to open a ticket with Microsoft. I don't believe per incident support is actually as expensive as one would expect, and I think the fee is refunded when a problem is proved to be a problem in their OS. Getting high enough up the chain on the ticket might be tricky and might require reproducing the issue over and over again, so it could be easier for a dev, but I just thought I'd point out that it's more of an option than anyone might realize. However, I don't use cgminer with Windows (I don't even have Win7 at home), so I can't really offer to help beyond the suggestion in this case, so this is just information for those more vested (either because they are effected or because someone offers them a donation for taking action). Further to this discussion, I've seen quite a few bug reports quite recently about this same dll in combination with firefox. While I do believe the bug is in the dll itself, I wonder if there's a common variable bringing it on? Are those who are having problems with the dll using IPV6 by any chance? |
|
|
|
|
This thread makes my head hurt. There is so much cognitive bias in the arguments for the devices that I'm dumbfounded.
|
|
|
|
|
Show Posts
