1 - Which are the best settings for Antminer S5 of expirytime-scantime-queue for solo-pool (ex. tbdice.org)?2 - If difficulty is set to 1024 cgminer (v4.8.0) not show share (Accepted 00000080 Diff 0/1024 ) and best share it remains 0 ...this is not a problem for normal pool but for solo pool it's ok? (if i change diff work fine= Accepted 3e047efc Diff 1.06K/341 )

1 - Which are the best settings for Antminer S5 of expirytime-scantime-queue for solo-pool (ex. tbdice.org)?2 - If difficulty is set to 1024 cgminer (v4.8.0) not show share (Accepted 00000080 Diff 0/1024 ) and best share it remains 0 ...this is not a problem for normal pool but for solo pool it's ok? (if i change diff work fine= Accepted 3e047efc Diff 1.06K/341 )

Thank you

ps: i use S5 with latest firmware (cgminer 4.8.0.)

Post to the S5 thread or to a thread that supports that cgminer fork. It's been posted several times (and is in capital letters in the thread topic) that this thread is for the OFFICIAL release of cgminer.

Post to the S5 thread or to a thread that supports that cgminer fork. It's been posted several times (and is in capital letters in the thread topic) that this thread is for the OFFICIAL release of cgminer.

Stop creating noise by pretending to be the responsible user of this forum, when in actual fact you are just signature-ad spamming. If you are un-happy about a post, just report it to the moderator rather than spam us with your nonsensical posts (you've also just done that in the S3 thread!).

Post to the S5 thread or to a thread that supports that cgminer fork. It's been posted several times (and is in capital letters in the thread topic) that this thread is for the OFFICIAL release of cgminer.

Stop creating noise by pretending to be the responsible user of this forum, when in actual fact you are just signature-ad spamming. If you are un-happy about a post, just report it to the moderator rather than spam us with your nonsensical posts (you've also just done that in the S3 thread!).

He's just stating the obvious, which in turn will help the person who posted the original message, who obviously doesn't know where to turn for help.

I don't see why you should have a problem with that.

A: Because it messes up the order in which people normally read text.Q: Why is top-posting such a bad thing?A: Top-posting.Q: What is the most annoying thing on usenet and in e-mail?

1 - Which are the best settings for Antminer S5 of expirytime-scantime-queue for solo-pool (ex. tbdice.org)?2 - If difficulty is set to 1024 cgminer (v4.8.0) not show share (Accepted 00000080 Diff 0/1024 ) and best share it remains 0 ...this is not a problem for normal pool but for solo pool it's ok? (if i change diff work fine= Accepted 3e047efc Diff 1.06K/341 )

Thank you

ps: i use S5 with latest firmware (cgminer 4.8.0.)

Post to the S5 thread or to a thread that supports that cgminer fork. It's been posted several times (and is in capital letters in the thread topic) that this thread is for the OFFICIAL release of cgminer.

ok thank you...but on S5 thread i had not received any response..I have no idea where to find answers

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.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

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.

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?

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

Server Can Occasionally Ask Miner to Change Share DifficultyDefault 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.

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).

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.

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.

I used ck's link to cg miner 4.9.2and 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 250Is 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 numbersI 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.

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.

Please support sidehack with his new miner project Send to : 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTrI mine alt coins with https://simplemining.net I see BTC as the super highway and alt coins as taxis and trucks needed to move transactions.

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.25262.50268.75275.00281.25287.50293.75300.00

306.25312.50318.75325.00331.25337.50343.75350.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.

Please support sidehack with his new miner project Send to : 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTrI mine alt coins with https://simplemining.net I see BTC as the super highway and alt coins as taxis and trucks needed to move transactions.

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