OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 539.

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: tucenaber on July 11, 2012, 06:00:22 AM

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

ZodiacDragon84

sr. member

Activity: 266

Merit: 250

The king and the pawn go in the same box @ endgame

Quote from: dankroxel on July 11, 2012, 07:44:16 PM

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

dankroxel

newbie

Activity: 30

Merit: 0

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

Hyphen

newbie

Activity: 20

Merit: 0

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.

bronan

hero member

Activity: 774

Merit: 500

Lazy Lurker Reads Alot

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

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: kano on July 09, 2012, 09:11:02 AM

Wrong.

...

Adjusting the abort time will not change the Hash rate unless there is something wrong either with the device or the computer's termios timing

If you are using 6.5 seconds to abandon jobs then you are aborting work too early.
However the reason you have to do that may be because you are using windows and the termios timing may not be accurate.

Well, in my setup, on Windows 7, abort time changes the hash rate. the utility does not change much, but hash rate is very sensitive to abort time.

Abort time lower than 8 seconds (80), increases the hash rate, higher than 8 secs (80) lowers the hash rate.

BTW, I've played with many timings, and 6.5 seconds abort time produce best utility rate. I don't care about the hash rate reported by the cgminer. Number of submitted, valid shares per minute is what makes money. So who cares if cgminer is reporting 410 or 210 Mh/s. If utility is 5.35, I'm a happy camper.

On Windows 7 (64bit), the new icarus code barely gets utility of 5.
Kano, maybe you optimized too much for Unix and Windows performance took a hit.

wind

member

Activity: 125

Merit: 10

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?

Aseras

hero member

Activity: 658

Merit: 500

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?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: tucenaber on July 11, 2012, 06:00:22 AM

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.

tucenaber

sr. member

Activity: 337

Merit: 252

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:

Quote

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

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: kano on July 10, 2012, 11:55:24 PM

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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

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)

tucenaber

sr. member

Activity: 337

Merit: 252

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:

Quote

[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:

Quote

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)

Quote

[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

Quote

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!

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: tucenaber on July 09, 2012, 04:32:02 AM

Decreasing the time from 112 to 60 results in an increased hashrate to ~275MH/s. About 25%. Better but no cigarr...

The Utility stays about the same. The total goes from about 69 to 70. But it was correct from the start. Theoretically my total hashrate is 4956MH/s, which should give a utility of 60 x 4.956e⁹/4295032833 = 69.23 shares/minute.

The hash rate is an estimate. If you put 80 as abort time, you'll get a better estimate.
If you put 90 or a 100, your hash rate estimate will be lower.

In my setup, the new icarus code does weird things (hash rates swing wildly), my utility rarely goes above 5/min.

With the old icarus code (some small mods by me, see my site) I get consistently 26.80/min out of my 5 icarus boards.
I stopped using the latest greatest icarus code as it is making me less money.

BTW, I'm using 6.5 secs to abandon previously submitted jobs.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: tucenaber on July 10, 2012, 06:47:59 AM

Quote from: -ck on July 10, 2012, 03:38:58 AM

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

sr. member

Activity: 337

Merit: 252

Quote from: -ck on July 10, 2012, 03:38:58 AM

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.

tucenaber

sr. member

Activity: 337

Merit: 252

Quote from: kano on July 10, 2012, 03:54:43 AM

Quote from: tucenaber on July 09, 2012, 10:01:30 PM

...

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 Wink

Thanks.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: somenick on July 09, 2012, 02:59:23 PM

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.

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: -ck on July 10, 2012, 03:38:58 AM

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! Sad

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

M

DiabloD3

legendary

Activity: 1162

Merit: 1000

DiabloMiner author

Quote from: somenick on July 09, 2012, 02:59:23 PM

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.

Huh, thats weird. cgminer uses pretty similar code to what I do.

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