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

[optimator]

What about if diff drops as in scenario B? Do you credit work to the new difficulty or does the old difficulty still apply?

I think for scenario B, the pool must either a) credit the miner the shares at the new difficulty; or b) push cleanjobs=true. There is an advantage for the pool op in pushing cleanjobs=true, but the visible result will be in stale rejects.

[1715492658]

1715492658

[1715492658]

1715492658

[mdude77]

With p2pool having upgrade pains, I've pointed my miners to eclipse and ozcoin respectively.

It seems eclipse is shipping me non integer difficulty work, ie, somewhere between 1 and 2.  I couldn't tell by the share output, because it always says x/1, but I see this on top:

Code:

(5s):1.928G (avg):1.963Gh/s | Q:167  A:1075  R:6  HW:0  E:644%  U:20.2/m
TQ: 0  ST: 7  SS: 1  DW: 328  NB: 7  LW: 1789  GF: 0  RF: 2  WU: 27.9

The WU is around what I expect U to be when dealing with difficulty 1 work.  Am I reading this right?

Any change we could get a decimal point or two in the cgminer output to show this?

Regards,

M

[-ck]

With p2pool having upgrade pains, I've pointed my miners to eclipse and ozcoin respectively.

It seems eclipse is shipping me non integer difficulty work, ie, somewhere between 1 and 2.  I couldn't tell by the share output, because it always says x/1, but I see this on top:

Code:

(5s):1.928G (avg):1.963Gh/s | Q:167  A:1075  R:6  HW:0  E:644%  U:20.2/m
TQ: 0  ST: 7  SS: 1  DW: 328  NB: 7  LW: 1789  GF: 0  RF: 2  WU: 27.9

The WU is around what I expect U to be when dealing with difficulty 1 work.  Am I reading this right?

Any change we could get a decimal point or two in the cgminer output to show this?

Not much point when we'll all be mining difficulties in the 10s to 100s soon.

[DrHaribo]

send: {"method":"mining.notify","params":[["1-c9","0000000000e3441ba33cf51d11a8aef12e8ae6d01a5bd54e8ec7cc9a9c22837b","01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff56037c9600094269744d696e746572062f503253482f2cfabe6d6d8c53896d9815717a31ffc5 135ccd79527cec9e360aba3738261e0a338a827eb60100000000000000136465760100000000000 000c900000000000000ffffffff0100f2052a010000001976a914616c05127d60e61407f52bce21 a4f894268cd89588ac00000000","",[],"00000002","1c018167","50b292ad",false]],"id":1}

! :-)

That did it, thanks!

[P_Shep]

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.

[Luke-Jr]

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

cgminer isn't switching to new work right away.

Here's the fix in bfgminer 2.9.3, though I'm not sure it will work as-is in cgminer without some other changes too.

[juhakall]

Noticed a share rejection problem with 2.9.5. I removed failover-only from my config because share leakage is lower, only ~0.01% of all accepted shares are sent to backup pools now. My setup on all rigs is the same, CoinLab as the main pool, BitMinter as first backup and Eclipse as last resort. All the accepted leaked shares go to BitMinter, and that's no problem anymore because they are so rare. However, my miners only gather rejects on Eclipse, about 10 rejects for every share leaked to BitMinter. No shares have been accepted on Eclipse so far, and one rig has already marked it as Rejecting.

If I also account for rejected leaked shares, the total amount is still only ~0.1%, so it doesn't matter much. But this definitely isn't behaving correctly now. I can help testing this if it's not obvious what the problem could be.

[Lem]

I removed failover-only from my config because share leakage is lower

I did the same. I can confirm that with 2.9.5 share leakage has actually gone back down to a negligible minimum.

Well done!

[-ck]

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.

This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises.

Try the EMC GBT server until it's resolved.

[Luke-Jr]

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.

This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises.

That wouldn't make them stale... and EMC accepts shares at the lower target for work issued before it changed...

[juhakall]

The share rejection problem I have on EMC (described a few posts ago) isn't connected to stratum. I'm using http://us2.eclipsemc.com:8337 as the URL and miner.php says it's not using stratum. I'm not sure if it's using GBT, though. How do I check that?

[P_Shep]

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.

This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises.

That wouldn't make them stale... and EMC accepts shares at the lower target for work issued before it changed...

I'm miss-labelling here, sorry. I didn't mean stale, I meant rejected (for whatever reason).

[kano]

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.

This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises.

That wouldn't make them stale... and EMC accepts shares at the lower target for work issued before it changed...

I'm miss-labelling here, sorry. I didn't mean stale, I meant rejected (for whatever reason).

Yes we all understood that ... except one 'person'

[Askit2]

My EMC rejects are 1.2% with stratum. I understand the post LP dump and I appreciate the chance at a paid share. The intermediate Rejected [Blah blah blah] (Unknown-Work). Usually this is in the middle of 2 other results found in a work unit or at least the 2nd submission at a time. Sometimes its first, sometimes last I guess.

It doesn't seem like unknown work. Things before it get accepted, after it also accepted. If the work was actually unknown wouldn't I expect more then a single reject in a batch of submissions? I suppose I could be piling up a result every so often that isn't accepted and on resubmit it is rejected. Expiry is likely a little high at 120s but my lower results are running the same.

Setup 1 BFL Single and CGMiner 2.9.5.

Before junior pipes up about GBT. I ran .2% rejects on GW, .8% on GBT, 1.2% on stratum on eclipse. All results on eclipse. The reduction of network traffic is far nicer then the slight reduction in rate.

Also on Stratum I am seeing a 856.X overall hashrate, Last week I managed 852.X with GBT and more network load. This could be new difficulty related or luck as it has only been on for 26K shares.

[-ck]

There's something else about stratum on EMC, and that appears to be lots of disconnects? That's another limitation of stratum, that once you disconnect the shares cannot be submitted on reconnect. Slush is going to have to add a reconnect option to it, or any disconnect of the socket will always be associated with shares lost if you're actively mining on it. Certainly it appears to be a combination of things and not just the frequent retargetting, although that is easy to see - the reject will say something like "share above target". "Unknown work" after longpoll is a true stale, work from the previous block. Not sure what's going on with GBT on EMC, but yes the rejects appear higher there too. For the time being you can still mine on getwork with --fix-protocol, but I'd rather see the pool issues sorted out.

[-ck]

Okay I see the problem here on EMC stratum.

Based on a commit luke-jr did to bfgminer, it seems he thinks that new work notification by stratum mandates that all work be thrown out in favour of the new work, because he FORCES the clean flag. However no other pool actually expects this, only forcing a clean when they actually send the work clean message. So I'm going to go out on a limb here and say the problem lies with the implementation of stratum on EMC, as coded up by luke-jr.

[Luke-Jr]

Okay I see the problem here on EMC stratum.

Based on a commit luke-jr did to bfgminer, it seems he thinks that new work notification by stratum mandates that all work be thrown out in favour of the new work, because he FORCES the clean flag. However no other pool actually expects this, only forcing a clean when they actually send the work clean message. So I'm going to go out on a limb here and say the problem lies with the implementation of stratum on EMC, as coded up by luke-jr.

No, I think new work notification should be used as soon as possible without throwing out the previous jobs, just like it is for getwork and GBT (which have an equivalent submitold indicator). This is implied by the current Stratum documentation:

clean_jobs - When true, server indicates that submitting shares from previous jobs don't have a sense and such shares will be rejected. When this flag is set, miner should also drop all previous jobs, so job_ids can be eventually rotated.

Admittedly, there is room for improvement in stratum here, since it could support 3 states:

• Previous jobs are invalid, don't send shares (getwork/GBT submitold=false; impossible with cgminer now)
• Previous jobs are valid, but please start using this immediately (getwork/GBT submitold=true; how cgminer interprets clean_jobs=false now)
• Previous jobs are valid; use this for new work at your convenience (how cgminer is interpreting clean_jobs=true now; no getwork/GBT equivalent)

Perhaps slush could clarify the current meaning, but it would be disappointing to learn stratum discards another fix for a problem we had already solved with getwork/GBT. Regardless of the current meaning, I intend to suggest the tristate when stratum's BIP process begins.

[kano]

Okay I see the problem here on EMC stratum.

Based on a commit luke-jr did to bfgminer, it seems he thinks that new work notification by stratum mandates that all work be thrown out in favour of the new work, because he FORCES the clean flag. However no other pool actually expects this, only forcing a clean when they actually send the work clean message. So I'm going to go out on a limb here and say the problem lies with the implementation of stratum on EMC, as coded up by luke-jr.

No, I think new work notification should be used as soon as possible without throwing out the previous jobs, just like it is for getwork and GBT (which have an equivalent submitold indicator). This is implied by the current Stratum documentation:

clean_jobs - When true, server indicates that submitting shares from previous jobs don't have a sense and such shares will be rejected. When this flag is set, miner should also drop all previous jobs, so job_ids can be eventually rotated.

Admittedly, there is room for improvement in stratum here, since it could support 3 states:

• Previous jobs are invalid, don't send shares (getwork/GBT submitold=false; impossible with cgminer now)
• Previous jobs are valid, but please start using this immediately (getwork/GBT submitold=true; how cgminer interprets clean_jobs=false now)
• Previous jobs are valid; use this for new work at your convenience (how cgminer is interpreting clean_jobs=true now; no getwork/GBT equivalent)

Perhaps slush could clarify the current meaning, but it would be disappointing to learn stratum discards another fix for a problem we had already solved with getwork/GBT. Regardless of the current meaning, I intend to suggest the tristate when stratum's BIP process begins.

Ah yes lets just ignore the GBT spec while we're at it and solve that piece of crap and do it properly

You changed your code and ignored the spec ... good idea that one

[-ck]

Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work?

[Askit2]

Okay I see the problem here on EMC stratum.

Based on a commit luke-jr did to bfgminer, it seems he thinks that new work notification by stratum mandates that all work be thrown out in favour of the new work, because he FORCES the clean flag. However no other pool actually expects this, only forcing a clean when they actually send the work clean message. So I'm going to go out on a limb here and say the problem lies with the implementation of stratum on EMC, as coded up by luke-jr.

No, I think new work notification should be used as soon as possible without throwing out the previous jobs, just like it is for getwork and GBT (which have an equivalent submitold indicator). This is implied by the current Stratum documentation:

clean_jobs - When true, server indicates that submitting shares from previous jobs don't have a sense and such shares will be rejected. When this flag is set, miner should also drop all previous jobs, so job_ids can be eventually rotated.

Admittedly, there is room for improvement in stratum here, since it could support 3 states:

• Previous jobs are invalid, don't send shares (getwork/GBT submitold=false; impossible with cgminer now)
• Previous jobs are valid, but please start using this immediately (getwork/GBT submitold=true; how cgminer interprets clean_jobs=false now)
• Previous jobs are valid; use this for new work at your convenience (how cgminer is interpreting clean_jobs=true now; no getwork/GBT equivalent)

Perhaps slush could clarify the current meaning, but it would be disappointing to learn stratum discards another fix for a problem we had already solved with getwork/GBT. Regardless of the current meaning, I intend to suggest the tristate when stratum's BIP process begins.

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?
Wow that seems unlikely. Apparenly EMC pays for invalids now for ~9 minutes. Or there is an issue more like Con said.
If I made a bet on this I would guess I had a legitimate share that will now not get paid. No disconect (unless it is hidden on the primary pool) (not debug, verbose or rpc debug). Not hold over stale (expiry isn't that high any more). It shouldn't be working on old work UNLESS I am paid virtually without punishment (Very doubtful).