Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 483. (Read 5805546 times)

newbie
Activity: 46
Merit: 0
ckolivas,

I know LTC is no more your favorite thing than Stratum is Luke-jr's. However a few of us are starting to see a lot of rejections with time-too-old issues. Do you have any insight what might be done to stop these? I mentioned it over at #ozcoin and Graet was kind enough to fire up an instance and he got "<@Graet> A:644 R:197 after 1.5 hours" so you can see its a ton of rejects I have seen 44-50% on my own miners with no other hardware errors etc.

Anything you can suggest?
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
Well judging by the error CL etc etc Is SDK installed I would start there.

Make sure when you installed you didn't just get a driver but the full install with the SDK. What OS are you using as that has a lot of effect on how to get it to work.
sr. member
Activity: 294
Merit: 250
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...?
hero member
Activity: 988
Merit: 1000
Quote
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.
vip
Activity: 1358
Merit: 1000
AKA: gigavps
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Quote
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.
legendary
Activity: 1795
Merit: 1208
This is not OK.
Quote
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
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
legendary
Activity: 1386
Merit: 1097
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.
sr. member
Activity: 467
Merit: 250
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".

legendary
Activity: 1795
Merit: 1208
This is not OK.
btw, will you be including jesus-miner's GBT code?

Also, how will the selection of protocol work... Automagic or manual?
legendary
Activity: 1795
Merit: 1208
This is not OK.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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
hero member
Activity: 988
Merit: 1000
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.
legendary
Activity: 1500
Merit: 1022
I advocate the Zeitgeist Movement & Venus Project.
Between the latest nVidia drivers and this latest release, my machine no longer crashes the driver when mining with CGMiner. Thanks!
legendary
Activity: 1540
Merit: 1001
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
full member
Activity: 208
Merit: 100
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
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Its probably the same bug i mentioned few pages earlier.
That we're working on Smiley
legendary
Activity: 2688
Merit: 1240
Its probably the same bug i mentioned few pages earlier.
hero member
Activity: 914
Merit: 500
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! Smiley

Thanks in advance!

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

http://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! Smiley
Jump to: