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

[kano]

Hope you'll find it, let me know if I can help you any further

Failed to find it trying to force GPU HW errors
I've made some more changes related to Icarus HW error handling - so now they are done (and awaiting to go into the git) I'll try find the cause of the GPU spin.
So, if you have time, I would greatly appreciate if you could drop by IRC again and help
Thanks

[kano]

...
Thanks Kano!
Yes i have noticed that this is not causing problems. It is not USB issue since dmesg shows nothing about USB unplug/plug events.
By the way this is debug version as you suggested, but still no core dumps:)
Best

Well the change is in my git and hopefully it will make it go away
In my Icarus branch at the moment:
 https://github.com/kanoi/cgminer/tree/icarus
and the pull request:
 https://github.com/ckolivas/cgminer/pull/316
(I've had it running a lot of the day on my Icarus rig)

[wndrbr3d]

I've been running into an error recently with the latest version of CGMiner that has resulted in client crashes on my two boxes. Both are Win32 mining scrypt, one uses a 5870 the other a 6870.

The issue I'm running into is that CGMiner starts to mine successfully for a bit then I start seeing "time-too-old" errors and Hardware Errors start shooting up to the point where cgminer crashes. I don't see this same behavior in 2.6.4, only in the latest 2.7.x branch.

Below is a screen shot of the issue. Any help isolating the problem is greatly appreciated!

Thanks in advance!

cgminer --scrypt -o http://thepool:8332 -u USER -p PASS --worksize 256 --shaders 1120 -g 1 --intensity 19 -d 1

https://i.imgur.com/2uyU5.png

55,378 hardware errors and -I 19 should really have already told you that you need to at LEAST reduce the intensity ...

I would agree if this same crashing+issue showed itself in the 2.6.x branch. I can run 2.6.4 without issue on those settings, it's 2.7.x that crashes out. I suppose I was submitting it more as a bug since something changed between version branches.

Thanks!

[ocminer]

Its probably the same bug i mentioned few pages earlier.

[kano]

Its probably the same bug i mentioned few pages earlier.

That we're working on

[pengoau]

Ok I'm getting back into this since btc is like $12~!

I lost all my settings as I deleted it as it was not worthwhile, anyway just doing this as a hobby since I leave my pc on most days due to bittorent heh.

Anyway whats some good settings for a HD6950? I'm currently running @ mem:core of 800:800 and intesity of 5, seemt o get about 325Mhas/sec is that good for my hardware?

Has someone gone to the trouble of making a cgiminer tweak guide?

Thanks

[mdude77]

Ok I'm getting back into this since btc is like $12~!

I lost all my settings as I deleted it as it was not worthwhile, anyway just doing this as a hobby since I leave my pc on most days due to bittorent heh.

Anyway whats some good settings for a HD6950? I'm currently running @ mem:core of 800:800 and intesity of 5, seemt o get about 325Mhas/sec is that good for my hardware?

Has someone gone to the trouble of making a cgiminer tweak guide?

Thanks

Check out:

https://en.bitcoin.it/wiki/Mining_hardware_comparison

M

[LightRider]

Between the latest nVidia drivers and this latest release, my machine no longer crashes the driver when mining with CGMiner. Thanks!

[Mobius]

Ok I'm getting back into this since btc is like $12~!

I lost all my settings as I deleted it as it was not worthwhile, anyway just doing this as a hobby since I leave my pc on most days due to bittorent heh.

Anyway whats some good settings for a HD6950? I'm currently running @ mem:core of 800:800 and intesity of 5, seemt o get about 325Mhas/sec is that good for my hardware?

Has someone gone to the trouble of making a cgiminer tweak guide?

Thanks

Check out:

https://en.bitcoin.it/wiki/Mining_hardware_comparison

M

You should be able to do I 9 with no problem.

[-ck]

As expected, implementing stratum was very much a huge change affecting multiple areas of cgminer.

Summary so far:

Code:

 6 files changed, 1230 insertions(+), 270 deletions(-)

After a week of hacking on it, it's about 1000 new lines of code in its first rough cut working version. It's been a lot of work to implement, and rather rewarding to see it working in action. There is currently a stratum branch in the git repository which includes the changes to date for the brave who wish to give it a go. Given the magnitude of changes, breakage is likely so it will be a while before the code settles down enough for me to feel comfortable releasing a version of cgminer including it.

https://github.com/ckolivas/cgminer/tree/stratum

[P_Shep]

Well done. Con

[P_Shep]

btw, will you be including jesus-miner's GBT code?

Also, how will the selection of protocol work... Automagic or manual?

[dlasher]

Here is my guide for people like me who are not familiar with linux to get cgminer running on a Raspberry Pi.  Note that dlasher and burger did 99% of the work here.  I just verified it and added some comments.  Thanks guys!  

Well done, nicely organized, good catch on the "libudev-dev".

[slush]

Also, how will the selection of protocol work... Automagic or manual?

As far as I can tell, it switch to Stratum automatically if pool advertises it, so there's no need to change of configuration. Just cgminer update is enough.

[-ck]

btw, will you be including jesus-miner's GBT code?

Also, how will the selection of protocol work... Automagic or manual?

I am implementing stratum first up as I believe going forward that it is the better suited protocol for pool mining based on a number of things I won't go into again here. The major disadvantage to stratum is that it needed a rewrite of great chunks of cgminer to work as it worked outside the bounds of all the machinery cgminer had in place for http communication and the very complex network scheduler that I had written into cgminer to make it scale. GBT is yet another competing standard which seemed to be designed  as a drop-in replacement for getwork that shared some of the ideas with it, and in the process, took on some of its disadvantages. So in actual fact it's less work to implement GBT, and while it claims to offer a lot more "features", none of those features are remotely relevant to how most of us mine. So I'm implementing stratum first as a show of support for what I believe is the better protocol.

Now Luke-jr has claimed, in his usual FUD way, that stratum is "bad for bitcoin" which is right up there for his standard of crap accusations. It seems the only reason he's so vehemently against stratum is that it was a competing protocol to what he was working on, and therefore anything he didn't do must be wrong in his eyes. As I said above, any extra features of GBT are going to be largely irrelevant to miners and there is not any point implementing them. On the other hand, GBT is yet another communication protocol that some pools are already supporting (basically because they're using his pool software so they get it by default). So in the future, after I release a stratum supporting version of cgminer, I will be implementing my own GBT support for the purposes of maintaining maximum compatibility with pools. Provided I have the time, I'm not planning on taking his code if I can help it.

Now you can try and hold Luke-jr to task over this and if he firmly believes stratum is bad for bitcoin, then he should not try and copy my implementation of it into his hostile fork and actually differentiate his software from mine, withholding support for stratum. However, he has shown that with scrypt for example, even though he was firmly opposed to litecoin mining, he took my implementation of it into his software because he was afraid he would lose his audience.

Within a few milliseconds of posting this I expect him to come and spam my forum thread with all sorts of bullshit rebuttal for what I just posted but he will do precisely what I predicted with pulling in my stratum code regardless. I have him on ignore in this forum, as I find wasting energy dealing with him absolutely pointless.


As for the selection of work, cgminer can detect stratum from either the way you input it ( stratum+tcp:// ) or if you put a stratum url in by mistake as http:// or with no prefix it will test to see if it's a stratum url first, or if the pool advertises stratum support in the getwork response it will automatically switch to it by itself. So if it all goes according to plan it should all just happen automatically.

[P_Shep]

It seems the only reason he's so vehemently against stratum is that it was a competing protocol to what he was working on, and therefore anything he didn't do must be wrong in his eyes.

Essentially what it comes down to.

As far as I can tell, we have:

GBT:
+ Easier to implement in existing code
- Larger bandwidth requirements
   - Includes redundant features for miners

Stratum:
+ Tiny bandwidth
   + Streamlined features for mining
- Difficult to implement in existing code


To my mind, Stratum wins. Maybe initially more difficult to roll out, but ultimately will hold out better as hash rates continue to increase.

[-ck]

It seems the only reason he's so vehemently against stratum is that it was a competing protocol to what he was working on, and therefore anything he didn't do must be wrong in his eyes.

Essentially what it comes down to.

As far as I can tell, we have:

GBT:
+ Easier to implement in existing code
- Larger bandwidth requirements
   - Includes redundant features for miners

Stratum:
+ Tiny bandwidth
   + Streamlined features for mining
- Difficult to implement in existing code


To my mind, Stratum wins. Maybe initially more difficult to roll out, but ultimately will hold out better as hash rates continue to increase.

In a nutshell yes. However the bandwidth requirements of both are so small that the advantage in that regard is no big deal. Stratum has advantages across block change and in terms of network latencies.

[jamesg]

In a nutshell yes. However the bandwidth requirements of both are so small that the advantage in that regard is no big deal. Stratum has advantages across block change and in terms of network latencies.

Thanks for all of the effort conman. It is appreciated.

[Mobius]

It seems the only reason he's so vehemently against stratum is that it was a competing protocol to what he was working on, and therefore anything he didn't do must be wrong in his eyes.

Essentially what it comes down to.

As far as I can tell, we have:

GBT:
+ Easier to implement in existing code
- Larger bandwidth requirements
   - Includes redundant features for miners

Stratum:
+ Tiny bandwidth
   + Streamlined features for mining
- Difficult to implement in existing code


To my mind, Stratum wins. Maybe initially more difficult to roll out, but ultimately will hold out better as hash rates continue to increase.

You forgot, their intention to reduce/eliminate pools (to paraphrase "they (pools) have too much power/influence") via GBT as an eventual p2pool way of mining. Otherwise why would they not have made bitcoind v0.7.0 backward compatible with existing pool software and allow new protocols to compete on an even playing field.

[c4n10]

Hello everyone,

I just replaced my 9600 gt oc with a 5870 Super OC and I am having trouble getting cgminer to recognize it. Every time I try to load I get the following:

Code:

C:\Documents and Settings\HP_Administrator.YOUR-4DACD0EA75.000\Desktop\cgminer-2
.7.5-win32\cgminer-2.7.5-win32>cgminer --scrypt -o http://lc.ozco.in:9332/ -u c4
n10.3 -p Mindfield1 -D -T --verbose --intensity 16 --worksize 128 --shaders 1600

 [2012-10-02 04:54:05] Started cgminer 2.7.5
 [2012-10-02 04:54:05] Error -1001: clGetPlatformsIDs failed (no OpenCL SDK inst
alled?)
 [2012-10-02 04:54:05] clDevicesNum returned error, no GPUs usable

All devices disabled, cannot mine!

I have the latest version of CCC and the latest version of SDK, anyone know what's up here...?