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

[kano]

...
ok thank you...but on S5 thread i had not received any response..

The well known problems in Bitmain's version are not in our master version.
So you need to ask them to do something about it.

queue is gone from master cgminer, and expiry/scantime should be left alone for solo BTC stratum.
The '1024' or 'power of 2' bug isn't in master cgminer.

[1534478373]

1534478373

[1534478373]

1534478373

[1534478373]

1534478373

[1534478373]

1534478373

[1534478373]

1534478373

[1534478373]

1534478373

[kano]

Anyone who updated and built from git since after 4.9.2 - this git commit that isn't in a release yet:
https://github.com/ckolivas/cgminer/commit/661088e6db6ba99b8de2a7b65bbc743bbfd994d4
Should re-get current git and rebuild.

I've reverted that commit until they supply a fixed version.
It causes a dump of 1 diff shares to be sent to the pool when you first connect - ignoring the pool difficulty sent on connect.

[NiceHashSupport]

Anyone who updated and built from git since after 4.9.2 - this git commit that isn't in a release yet:
https://github.com/ckolivas/cgminer/commit/661088e6db6ba99b8de2a7b65bbc743bbfd994d4
Should re-get current git and rebuild.

I've reverted that commit until they supply a fixed version.
It causes a dump of 1 diff shares to be sent to the pool when you first connect - ignoring the pool difficulty sent on connect.

Does the pool where you tested this set diff before first job or does it send job first and then hoping that miner will blindly know the diff that is wanted for this job?

[kano]

Anyone who updated and built from git since after 4.9.2 - this git commit that isn't in a release yet:
https://github.com/ckolivas/cgminer/commit/661088e6db6ba99b8de2a7b65bbc743bbfd994d4
Should re-get current git and rebuild.

I've reverted that commit until they supply a fixed version.
It causes a dump of 1 diff shares to be sent to the pool when you first connect - ignoring the pool difficulty sent on connect.

Does the pool where you tested this set diff before first job or does it send job first and then hoping that miner will blindly know the diff that is wanted for this job?

The change (as stated in the pull request) is to effectively do exactly what the problem is.
The issue is, of course, that it shouldn't do that on the first diff sent from the pool.

cgminer has to have a default diff until the pool sends a diff - this is one of the side effects of the problem in stratum of separation of diff from work - that we both pointed out to slush and eleuthria, and they ignored. Oh well.

[NiceHashSupport]

Anyone who updated and built from git since after 4.9.2 - this git commit that isn't in a release yet:
https://github.com/ckolivas/cgminer/commit/661088e6db6ba99b8de2a7b65bbc743bbfd994d4
Should re-get current git and rebuild.

I've reverted that commit until they supply a fixed version.
It causes a dump of 1 diff shares to be sent to the pool when you first connect - ignoring the pool difficulty sent on connect.

Does the pool where you tested this set diff before first job or does it send job first and then hoping that miner will blindly know the diff that is wanted for this job?

The change (as stated in the pull request) is to effectively do exactly what the problem is.
The issue is, of course, that it shouldn't do that on the first diff sent from the pool.

cgminer has to have a default diff until the pool sends a diff - this is one of the side effects of the problem in stratum of separation of diff from work - that we both pointed out to slush and eleuthria, and they ignored. Oh well.

If pools do not follow specifications, then make them follow. Usually after some time, they adopt.

[kano]

Anyone who updated and built from git since after 4.9.2 - this git commit that isn't in a release yet:
https://github.com/ckolivas/cgminer/commit/661088e6db6ba99b8de2a7b65bbc743bbfd994d4
Should re-get current git and rebuild.

I've reverted that commit until they supply a fixed version.
It causes a dump of 1 diff shares to be sent to the pool when you first connect - ignoring the pool difficulty sent on connect.

Does the pool where you tested this set diff before first job or does it send job first and then hoping that miner will blindly know the diff that is wanted for this job?

The change (as stated in the pull request) is to effectively do exactly what the problem is.
The issue is, of course, that it shouldn't do that on the first diff sent from the pool.

cgminer has to have a default diff until the pool sends a diff - this is one of the side effects of the problem in stratum of separation of diff from work - that we both pointed out to slush and eleuthria, and they ignored. Oh well.

If pools do not follow specifications, then make them follow. Usually after some time, they adopt.

Eh?

[elbandi]

If pools do not follow specifications, then make them follow. Usually after some time, they adopt.

Eh?

From Stratum Mining Protocol official documentation (bold is marked by me):

Server Can Occasionally Ask Miner to Change Share Difficulty
Default share difficulty is 1 (big-endian target for difficulty 1 is 0x00000000ffff0000000000000000000000000000000000000000000000000000), but server can ask you anytime during the session to change it:

{ "id": null, "method": "mining.set_difficulty", "params": [2]}
This Means That Difficulty 2 Will Be Applied to Every Next Job Received From the Server.

Let's say a telnet to your pool:

[L0] {"id": 1, "method": "mining.subscribe", "params": []}
[L1] {"result": [[["mining.notify", "00097c41"]], "20a6a503", 8], "id": 1, "error": null}
[L2] {"params": ["55c69c0300006fdc", "a3b32fc515975727a8fe91857c6f4f71a4359df1117c96430000000000000000", ".....", "1814dd04", "55d20bf8", true], "method": "mining.notify", "id": null}
[L3] {"params": [1042], "method": "mining.set_difficulty", "id": null}
...
[L4] {"method": "mining.notify", "params": ["55c69c0300006ff6", "295d51c341c96d1d7690ec202fddef62841374930cb892270000000000000000", "....", "1814dd04", "55d20e33", true], "id": null}

L0: this is the client subscribe
L1: pool response for clien subscribe
L2: first mining.notify ->  share difficulty calculates to 1 (default share difficulty based on stratum mining doc)
L3: change the difficulty to 1042 for next job
L4: next mining.notify -> share difficulty sould calculate to 1042!

The cgminer has the "bug": apply the difficulty for current job: so L2 job has 1042 sharediff. this conflict with mining doc.

Solutions:

• fix the doc: "Applied to Every Next Job" -> "Applied to Every Current Job"
• fix cgminer (with the patch) and fix your pool: send the set_difficulty first and mining.notify next

[-ck]

The cgminer has the "bug": apply the difficulty for current job: so L2 job has 1042 sharediff. this conflict with mining doc.

Solutions:

• fix the doc: "Applied to Every Next Job" -> "Applied to Every Current Job"
• fix cgminer (with the patch) and fix your pool: send the set_difficulty first and mining.notify next

Since Kano so often is so eloquent with his explanations (heh) I may as well elaborate. The issue is that following the standard destroys the startup of many devices by using diff1 until the next stratum update. Most of the low power controllers (like those in antminer S*) fall over trying to create that many shares and just about every pool would be seriously annoyed to get every miner sending their first 30 or 60 seconds of shares at diff1, especially with 5+ TH miners available. All pools would be affected by this. This is what I meant by the default behaviour of cgminer since stratum was first added is "robust". If you want to add the old/next diff idea back in you need to add a workaround for startup that veers off the standard. Standards are fine and all but real world workarounds for problems with the standard are essential (and a huge part of making cgminer practical solutions for today's mining).

[NiceHashSupport]

The cgminer has the "bug": apply the difficulty for current job: so L2 job has 1042 sharediff. this conflict with mining doc.

Solutions:

• fix the doc: "Applied to Every Next Job" -> "Applied to Every Current Job"
• fix cgminer (with the patch) and fix your pool: send the set_difficulty first and mining.notify next

Since Kano so often is so eloquent with his explanations (heh) I may as well elaborate. The issue is that following the standard destroys the startup of many devices by using diff1 until the next stratum update. Most of the low power controllers (like those in antminer S*) fall over trying to create that many shares and just about every pool would be seriously annoyed to get every miner sending their first 30 or 60 seconds of shares at diff1, especially with 5+ TH miners available. All pools would be affected by this. This is what I meant by the default behaviour of cgminer since stratum was first added is "robust". If you want to add the old/next diff idea back in you need to add a workaround for startup that veers off the standard. Standards are fine and all but real world workarounds for problems with the standard are essential (and a huge part of making cgminer practical solutions for today's mining).

Everything would be fine, if pools simply sent out diff before first job. How hard is it to do that?

Oh wait... maybe the problem is that your own ckpool implementation DOESN'T do that thus doesn't follow stratum specifications.

[-ck]

Everything would be fine, if pools simply sent out diff before first job. How hard is it to do that?

Oh wait... maybe the problem is that your own ckpool implementation DOESN'T do that thus doesn't follow stratum specifications.

Are you having fun yet? I guess you really never want this change merged in any form with that attitude. Remember you're the only proxy pool that is affected in any beneficial way due to constantly dropping connections and switching upstream pools and changing diff too often as a result. I guess I'll leave you to talk to Kano instead.

[philipma1957]

I have a question about sidehack's usb sticks.

I used ck's link to cg miner 4.9.2
and I used ck's link to zadig.
both work and I can run those usb sticks as if they are ant miner u2's  but the support in the stock build of cgminer ends at freq 250
Is this going to be increased to freq 300 or freq 350

Frankly I have spent a few hours here and there trying to use therealsteves files and instructions to upgrade the freq support numbers
I did succeed in screwing up my windows 7 builds on 2 pc's and have given up trying to do this.

I wondered if I missed an upgrade to the cg 4.9.2 build or if u2-u3 freq support stops at 250

I asked about this about a month ago in this thread and I am reviewing the thread so if you did do it and I missed your answer please let me know.

Best regards phil

this was the post

Hi ck and kano

I have been testing sidehack's

new usb sticks in this thread.

https://bitcointalk.org/index.php?topic=1086011.0


I used the 4.9.2 build from the first page of this thread.

and the sticks work great up to  freq 250

is it possible you can add support from  freq 250 to  freq 300

that would be :

 256.25
 262.50
 268.75
 275.00
 281.25
 287.50
 293.75
 300.00

 Side hack's sticks use your cgminer software and base it on your U-3 part of the build.

Basically I am really poor on the software end of the game. and cgminer is too hard for me to add these freq's

I use window's 7 to run my gear.

thanks phil

maybe in the 4.9.3 build.

[-ck]

both work and I can run those usb sticks as if they are ant miner u2's  but the support in the stock build of cgminer ends at freq 250
Is this going to be increased to freq 300 or freq 350

U2 or U3? They're quite different.

Code:

--anu-freq <arg>    Set AntminerU1/2 frequency in MHz, range 125-500 (default: 250.0)
--au3-freq <arg>    Set AntminerU3 frequency in MHz, range 100-250 (default: 225.0)                                                               

[philipma1957]

both work and I can run those usb sticks as if they are ant miner u2's  but the support in the stock build of cgminer ends at freq 250
Is this going to be increased to freq 300 or freq 350

U2 or U3? They're quite different.

Code:

--anu-freq <arg>    Set AntminerU1/2 frequency in MHz, range 125-500 (default: 250.0)
--au3-freq <arg>    Set AntminerU3 frequency in MHz, range 100-250 (default: 225.0)                                                              

U3 as I went back and double checked  

His sticks are seen as u3 and your stock cg 4.9.2 stops at freq 250 for the U3

TheRealSteve did a set of files adding support up to 425 for it but my programming skills are weak I simply have made a mess of 2 windows 7 builds attempting to follow his instructions to extend the top end  from 250 to 400 freq.

If you could add in freq support higher the 250  for the U3   it will help the sidehack usb stick buyers.

 
250.00 ------- this is the cutoff now


256.25
262.50
268.75
275.00
281.25
287.50
293.75
300.00


306.25
312.50
318.75
325.00
331.25
337.50
343.75
350.00

What ever can be added from 256.25 to 350.00   would be good.  

Even from 256.25 to 300.00 would be good.

Thanks.

[TheRealSteve]

He meant U3. ("Warning - while you were typing a new reply has been posted. You may wish to review your post." - that sneak..)

Phil, I can always send you the binary I'm using, as long as you don't mind all the funky extra stats.  Or wait a little longer for Novak/sidehack to make a build available that includes their driver (so that it'll actually be recognized as a Compac) and some tweaks (more gentle current draw on init).

That's a bit separate from the question in general, though.  Perhaps higher frequencies could be added regardless, although I'm not sure that shouldn't come with a --whyesidolovefire flag for higher frequencies in case somebody tries it on an actual U3

[-ck]

U3 as I went back and double checked  

His sticks are seen as u3 and your stock cg 4.9.2 stops at freq 250 for the U3

Looks like you're using windows if you mention zadig.

Try this binary (accepts same range as U2, up to 500):
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

You can use arbitrary values, cgminer will find the closest that works.

[philipma1957]

U3 as I went back and double checked  

His sticks are seen as u3 and your stock cg 4.9.2 stops at freq 250 for the U3

Looks like you're using windows if you mention zadig.

Try this binary (accepts same range as U2, up to 500):
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

You can use arbitrary values, cgminer will find the closest that works.

thanks I got a stick to works at freq 300!

working on the second stick

[prachait]

Hello, I have installed and using the following. mining for litecoin only

Fail. Cgminer doesn't mine litecoin or without mining hardware. Seek help in the altcoin subforums using other software.

lol ............ and from last 10 days,  I am telling my cgmine to mine alone without hardware
and giminer can not work on VPS or standalone PC

wow, and I have invested so many hours to know "cgminer can not miner by itself " so as on VPS alone, on google also

on irc Lightsword told me
to miner bitcoin with usb you need a miner like this https://bitmaintech.com/productDetail.htm?pid=00020150109104550452NTD3NdYY0669

Anyways, Thanks for the support team for educating me, and I wish the post to live here, for new comers in mining.

Prachait

[philipma1957]

 both sticks are working at freq 300  thanks again.

[splat44]

Does this version supports gridseed asic miner 80 chip two blade?

I recall reading something on Version 3.7.2 which most reports indicate it has problem recognizing two blade or more!

It be great to know following settings inside *.bat file
- recognizing two blade
- scryp option

I am speaking of windows version!

[kano]

Does this version supports gridseed asic miner 80 chip two blade?

I recall reading something on Version 3.7.2 which most reports indicate it has problem recognizing two blade or more!

It be great to know following settings inside *.bat file
- recognizing two blade
- scryp option

I am speaking of windows version!

No altcoin support whatsoever in master cgminer.