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

[mdude77]

Expire was added in cgminer 2.4.4

Expire=10 was a bug in much pool software. It did not make sense at all to have that value for anything but p2pool so the scantime is used if it is longer than expire (expire should be more like 120 seconds). This can't be creating duplicates though.

p2pool has a recent bug where duplicate work items are sent out regardless of the mining software. Anyone on p2pool?

Lots going on folks.... There is always more than meets the eye.

That explains the dupes.  I'm getting them a plenty! 

I'm trying p2pool (again) for a week.  So far the results have been dismal, and I'm having a hard time convincing myself to continue through the week.

M

[-ck]

cgminer has stale x2 greater than DiabloMiner
on deepbit
(0.24%)   Prop.
(0.21%)   Prop.
(0.19%)   Prop.
(0.23%)   Prop.
(0.11%)   Prop.  - DiabloMiner
(0.20%)   Prop.
(0.20%)   Prop.
(0.23%)   Prop.
(0.22%)   Prop.
(0.24%)   Prop.
(0.37%)   Prop.
(0.22%)   Prop.

Try dropping intensity by 1 or number of gpu threads by 1. Perhaps you're just over the efficiency/time to search peak.

[tucenaber]

...

They are different:
[2012-07-09 18:10:45] Icarus 8 sent: b586fa1de5c...c6d325e1c207d00...003194091ae002fb4f58386ba3
[2012-07-09 18:10:45] DBG: sending http://hack:9332 submit RPC call: {...9803830ca439defe9a1cea36b38584ffb02bc1a09943186654dc20000008...
[2012-07-09 18:10:45] Icarus 5 sent: b586fa1de5c...c6d325e1c207d00...003194091adf02fb4f58386ba3
[2012-07-09 18:10:45] DBG: sending http://hack:9332 submit RPC call: {...9803830ca439defe9a1cea36b38584ffb02981a099431a3ee925c0000008...

If you look at the proof of the second one it will be different of course also
When time is rolled, the data is only very slightly different of course ...

i.e. they are not duplicate shares in the above example

Oh man, I'm very seldom not uncareful Thanks.

[tucenaber]

Expire was added in cgminer 2.4.4

Expire=10 was a bug in much pool software. It did not make sense at all to have that value for anything but p2pool so the scantime is used if it is longer than expire (expire should be more like 120 seconds). This can't be creating duplicates though.

p2pool has a recent bug where duplicate work items are sent out regardless of the mining software. Anyone on p2pool?

Lots going on folks.... There is always more than meets the eye.

Well yeah, I'm on p2pool. So, if expire doesn't make any sense what headers should be used by p2pool? Should I set --scan-time to 10 perhaps?

Neither the p2pool software nor cgminer logs the getwork reply, so I'm adding that and sees what happens.

[-ck]

Expire was added in cgminer 2.4.4

Expire=10 was a bug in much pool software. It did not make sense at all to have that value for anything but p2pool so the scantime is used if it is longer than expire (expire should be more like 120 seconds). This can't be creating duplicates though.

p2pool has a recent bug where duplicate work items are sent out regardless of the mining software. Anyone on p2pool?

Lots going on folks.... There is always more than meets the eye.

Well yeah, I'm on p2pool. So, if expire doesn't make any sense what headers should be used by p2pool? Should I set --scan-time to 10 perhaps?

Neither the p2pool software nor cgminer logs the getwork reply, so I'm adding that and sees what happens.

Yes I guess you should set scantime to 10 seconds for now. In a future version I'll actually honour what otherwise appears to be a bogus roll expire time if the pool really wants that.

[tucenaber]

Here is an example of duplicates I get. Is there a simple explanation for this? (I might add that my miner doesn't handle the excessive logging very well becase of the puny USB-drive it is running from)

from cgminer debug log:

[2012-07-10 21:46:42] PROOF OF WORK RESULT: true (yay!!!)
 [2012-07-10 21:46:42] ICA0                | (5s):117.8 (avg):215.1 Mh/s | A:39 R:10 HW:0 U:3.3/m
 [2012-07-10 21:46:41] HTTP hdr(Content-Length): 58
 [2012-07-10 21:46:41]  Proof: 00000000a89439acea9673042010653694b76b6bcae528ec034bd94144fe476b
Target: 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
TrgVal? YES (hash < target)
 [2012-07-10 21:46:42] Pushing submit work to work thread

p2pool debug log:

2012-07-10 21:46:42.614994 > "Miner digger @ 192.168.1.102 submitted work: u'000000018e45fff93abc335ff6468d63036f5f368732cd938f253ede000008b500000000adc302d ba93ec61b888909f957f8b07bc7c5e265504899d9b44ccfbe14d0d9d94ffc86ac1a099431d35d63 bd00000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000'"
2012-07-10 21:46:42.615215 > "Submitted header: {'nonce': 3546112957, 'timestamp': 1341949612, 'merkle_root': 9415264709392722949772953808229952210827103327730856756643112439749055546075L, 'version': 1, 'previous_block': 13995169685392530026568800876350891503467619823386489753305081L, 'bits': FloatingInteger(bits=0x1a099431, target=0x994310000000000000000000000000000000000000000000000L)}"
2012-07-10 21:46:42.615439 > 'header hash: 00000000a89439acea9673042010653694b76b6bcae528ec034bd94144fe476b'

a few seconds later from cgminer log (it says nothing about submitting stale work)

[2012-07-10 21:46:47] PROOF OF WORK RESULT: true (yay!!!)
 [2012-07-10 21:46:47] ICA7                | (5s):199.8 (avg):212.7 Mh/s | A:44 R:5 HW:0 U:3.7/m
 [2012-07-10 21:46:46] HTTP hdr(Content-Length): 58
 [2012-07-10 21:46:46]  Proof: 00000000a89439acea9673042010653694b76b6bcae528ec034bd94144fe476b
Target: 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
TrgVal? YES (hash < target)
 [2012-07-10 21:46:47] Pushing submit work to work thread

and p2pool responds

2012-07-10 21:46:47.873337 > "Miner digger @ 192.168.1.102 submitted work: u'000000018e45fff93abc335ff6468d63036f5f368732cd938f253ede000008b500000000adc302d ba93ec61b888909f957f8b07bc7c5e265504899d9b44ccfbe14d0d9d94ffc86ac1a099431d35d63 bd00000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000'"
2012-07-10 21:46:47.873639 > "Submitted header: {'nonce': 3546112957, 'timestamp': 1341949612, 'merkle_root': 9415264709392722949772953808229952210827103327730856756643112439749055546075L, 'version': 1, 'previous_block': 13995169685392530026568800876350891503467619823386489753305081L, 'bits': FloatingInteger(bits=0x1a099431, target=0x994310000000000000000000000000000000000000000000000L)}"
2012-07-10 21:46:47.873877 > 'header hash: 00000000a89439acea9673042010653694b76b6bcae528ec034bd94144fe476b'
2012-07-10 21:46:47.998484 > Worker digger @ 192.168.1.102 submitted share 00000000a89439acea9673042010653694b76b6bcae528ec034bd94144fe476b more than once!

[kano]

What you are looking for is the work that produced the 2 shares and where it came from.

If p2pool sent the same work twice then that would be explanation #1
If cgminer rolled the work and produced 2 pieces of work the same that would be explanation #2
If the work sent to both of the Icarus was different but the results ended up the same that would be explanation #3

1) would be caused by something in p2pool
2) would be a problem with the rolling code
3) would probably be caused by some sort of static variable in the Icarus code overwriting another icarus device data

I certainly have no idea which it is, but you should be able to work that out, either from the current full cgminer logs, or with adding an extra debug somewhere in cgminer to show the incoming work (if it doesn't already show that)

Once you have a log showing all 3 pieces of information (getwork, work sent to Icarus, results) for a duplicate pair of shares, we can then determine where the problem is and fix it (or pass it on to p2pool to fix)

[mdude77]

What you are looking for is the work that produced the 2 shares and where it came from.

If p2pool sent the same work twice then that would be explanation #1
If cgminer rolled the work and produced 2 pieces of work the same that would be explanation #2
If the work sent to both of the Icarus was different but the results ended up the same that would be explanation #3

1) would be caused by something in p2pool
2) would be a problem with the rolling code
3) would probably be caused by some sort of static variable in the Icarus code overwriting another icarus device data

I certainly have no idea which it is, but you should be able to work that out, either from the current full cgminer logs, or with adding an extra debug somewhere in cgminer to show the incoming work (if it doesn't already show that)

Once you have a log showing all 3 pieces of information (getwork, work sent to Icarus, results) for a duplicate pair of shares, we can then determine where the problem is and fix it (or pass it on to p2pool to fix)

As I've said in the p2pool thread, I've seen this dupe message with phoenix as well.  I seem to get it more on cgminer, but I definitely see it with phoenix.

M

[tucenaber]

I think I know what's going on now. P2pool assumes that the miner will not roll ntime more than 10 seconds into the future (because it sets X-Roll-NTime to "expire=10"). At every work request it increments ntime by 12 and returns that.

cgminer doesn't respect the short expire, and rolls more than that. The two programs rolls independently and every so often they clash.

This is a short version of the p2pool log:

long poll returns new work:
  ntime: 1341949597, id: 157
result from miner:          
  ntime: 1341949618, nonce: 2503472672
  ntime: 1341949602, nonce: 3756563217
work request:
  ntime: 1341949609 (1341949597+12), id: 157
result from miner:
  ntime: 1341949604, nonce: 0474846110
  ntime: 1341949597, nonce: 1088064670
  ntime: 1341949598, nonce: 0826850881
  ntime: 1341949612, nonce: 3546112957, hash: 00000000a89439acea9673042010653694b76b6bcae528ec034bd94144fe476b
  ntime: 1341949600, nonce: 2986584650
  ntime: 1341949614, nonce: 4073111605
work request:
  ntime: 1341949621 (1341949597+24), id: 157
result from miner:
  ntime: 1341949618, nonce: 2503472672
  ntime: 1341949610, nonce: 2498371303
  ntime: 1341949612, nonce: 3546112957, hash: 00000000a89439acea9673042010653694b76b6bcae528ec034bd94144fe476b

[-ck]

I think I know what's going on now. P2pool assumes that the miner will not roll ntime more than 10 seconds into the future (because it sets X-Roll-NTime to "expire=10"). At every work request it increments ntime by 12 and returns that.

cgminer doesn't respect the short expire, and rolls more than that. The two programs rolls independently and every so often they clash.

Thanks, see my post in the p2pool thread. This is more about interpretation of the expire= parameter than anything else.

[Aseras]

2.5 has caused me HUGE problems. Every miner but 1 mines a couple shares and stops. Just sits there. 2.4.4 did something similar. I dropped back to 2.4.3 and everything is peachy.

What changed between them?

[wind]

Can't compile

Code:

  CC     cgminer-util.o
util.c: In function 'nmsleep':
util.c:703:7: error: void value not ignored as it ought to be
make[2]: *** [cgminer-util.o] Error 1
make[2]: Leaving directory `/home/z/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/z/cgminer'
make: *** [all] Error 2

any suggestion?

[bronan]

I have the same 2.4.4 and 2.5.0 causing massive problems
So went back to 2.4.3 which seems the only good version for now

[Hyphen]

2.5.0 seems to lock my fan speed at 63% on a 5870 of mine.
Automatic fan speed was turned off and I had sapphire set to 85% fan speed.
CGMiner wouldn't let me change it back to 85%.
Switched back to 2.4.1 and everything went back to normal.

[dankroxel]

Why is my AVG picking up a key logger when I download this?

[ZodiacDragon84]

Why is my AVG picking up a key logger when I download this?

Because some unscrupulous types have used the software in a malicious manner, and most AVGs have flagged it as malware of one form or another

[mdude77]

I think I know what's going on now. P2pool assumes that the miner will not roll ntime more than 10 seconds into the future (because it sets X-Roll-NTime to "expire=10"). At every work request it increments ntime by 12 and returns that.

cgminer doesn't respect the short expire, and rolls more than that. The two programs rolls independently and every so often they clash.

Every so often?  How much hash power do you have?  I'm seeing it all the time. 

After your hack, it was driving cgminer crazy "pool 2 not providing work fast enough" and diverting work to my backup pools.  p2pool was showing 1/2 my normal local hash power.  Just to make sure I wasn't doing something wrong with python, I put that line back in, and the dupe messages are back, but I'm back up to my normal local hashing power.

M

[-ck]

I have the same 2.4.4 and 2.5.0 causing massive problems
So went back to 2.4.3 which seems the only good version for now

Well that's rather non-specific. Information regarding hardware, command line options and debugging output run with "--verbose --debug -T" added might be helpful, as it says in the readme.

[tucenaber]

Every so often?  How much hash power do you have?  I'm seeing it all the time. 

After your hack, it was driving cgminer crazy "pool 2 not providing work fast enough" and diverting work to my backup pools.  p2pool was showing 1/2 my normal local hash power.  Just to make sure I wasn't doing something wrong with python, I put that line back in, and the dupe messages are back, but I'm back up to my normal local hashing power.

Ok ,all the time. Every few seconds.

I also never said it was the final solution, I said it was a short term fix for myself, and also a way to show if I was correct or not. The long term fix is probably to do it the other way around, but that require more than a one liner.

[jjiimm_64]

I would just like to chime in about how cgminer sends misc shares to backup pools when not busy enough..


my 4th backup pool is solo (as i think all miners should have solo as final backup to protect network)

well cgminer found me this block https://blockchain.info/block-height/188729 a couple of hours ago.. what are the odds?


thank you ckolivas