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

girafon

member

Activity: 60

Merit: 10

Not sure this is intended or not : using cgminer 2.9.5 under windows7 (64), downloaded from http://ck.kolivas.org/apps/cgminer/cgminer-2.9.5-win32.7z while connected to a GBT-enabled pool, the "Q" value reported by cgminer stays at "3" and won't change, even after hours of running.

This gives giant efficiency values (which may alter the various load-balance algorithms ?)

Part of my conf file:

Code:

"failover-only" : true,
"submit-stale" : false,

"intensity" : "d",
"gpu-threads" : "1",
"gpu-dyninterval" : "7",

"expiry" : "110",
"scan-time" : "60",

"log" : "1",
"queue" : "1",

EDIT : downgrading to 2.9.4 fixes that "issue" ; "Q" indicator increases again.

optimator

sr. member

Activity: 351

Merit: 250

Quote from: Luke-Jr on November 27, 2012, 07:57:18 AM

Well, if you can't roll ntime (sounds like a major flaw to me)

Not a flaw - just not needed.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

With the clarifications from slush, I've fixed 2 bugs in eloipool's stratum server:

clean_jobs is now sent true when previous jobs are immediately invalid
idle job updates occur every 55 seconds instead of 96 (stratum expects a 60 second grace window on old jobs)

This should get things working in the new block case of cgminer, but the fact that cgminer was still working on an old job after 24 seconds (at 800+ Mh/s) means it isn't switching to the new job when giving devices more work right away, so there's still a (cgminer) bug there (althrough the reduced 55 second update period will likely avoid that being as common).

Note that these changes won't affect EMC until Inaba updates it there.

slush

legendary

Activity: 1386

Merit: 1097

Looks like there's discrepancy between your and mine expectations about the ideal protocol. I've been focused to minimalistic design, and the lack of any extended features is benefit for me. I'm open to designing some (optional) calls like "report me your stale ratio", which will do the same job, it allows handy graphics on pool website, but it doesn't make the protocol core more complicated.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: slush on November 27, 2012, 08:55:27 AM

Quote from: Luke-Jr on November 27, 2012, 07:57:18 AM

How do pools say "previous job remain valid for N more seconds"?

Is there any use case for this feature? Except pools which "pay for stales" (=pay bad miners on behalf good ones).

Um, yes? So you don't need to keep around old jobs indefinitely...

Quote from: slush on November 27, 2012, 08:55:27 AM

Quote

This was an important fix added to getwork longpolling

Is there any pool actually using it? As we're primary talking about bitcoin mining, there's no motivation to work with stale shares on pool side...

Motivation: Don't lie to miners about their stale rate.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: Luke-Jr on November 27, 2012, 07:57:18 AM

How do pools say "previous job remain valid for N more seconds"?

Is there any use case for this feature? Except pools which "pay for stales" (=pay bad miners on behalf good ones).

Quote

This was an important fix added to getwork longpolling

Is there any pool actually using it? As we're primary talking about bitcoin mining, there's no economic motivation to work with stale shares on pool side...

Quote

avoid losing merged mining shares in some cases.

Well, this is valid point. We can discuss if losing less than 0.1% of merged mining shares is worth of complicating the mining protocol. I'm personally strictly for "keep it simple" and minimalistic design, otherwise implementations became monsters full of checking edge cases. Actually there's only one condition in whole Stratum protocol, and it is (I think necessary) "clean_jobs" flag. The rest is plain simple algorithm without exceptions.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: hahahafr on November 27, 2012, 07:21:51 AM

Quote from: kano on November 27, 2012, 03:28:04 AM

Quote from: crazyates on November 27, 2012, 12:31:58 AM

Quote from: hahahafr on November 26, 2012, 11:45:48 PM

Quote from: crazyates on November 26, 2012, 11:23:04 PM

Ya my first several shares are usually rejects. I am mining over wifi, with about a dozen+ other computers on the network, so DCs are a fact of life. Still, I can live with 0.3% for now. Wink

Don't go further. This is the issue.

I'm not complaining. I know it's a problem, but one I sorta have to live with. Tongue

... only until the current stratum problem is resolved and we move on to 'discussing' the reconnect issue and fixing that

I've read a certain number of posts from Kano speaking of these problems with Stratum now. If I believe Kano, it looks like the solution are somewhat trivial to implement, by just modifying the specifications we would be good to go. In 2 months from now on, Stratum will be the de facto standard protocol (because GBT has too much stales), now is a good time to correct forgotten cases/issues by Slush, not in 2 months. Undecided

I've considered (and mentioned to one) a way to solve this

Ask a pool to implement it fixed so they can call it something else (since it isn't what slush wants he has no claim over it) and then all the other pools can see it's better and switch over to it.
If it goes on for much longer I'll try to push this.

LOL at above post, he's getting lonely with his GBT and BarbieMiner that's people are slowly realising what's wrong with it and no one wants

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: optimator on November 27, 2012, 03:10:30 AM

Quote from: Luke-Jr on November 26, 2012, 10:23:46 PM

Stratum jobs can be used infinitely, until the block is invalid or the pool expires the job. Unlike getwork, there is no 2³² nonce limit.

True. But there is a limit to ntime. If a pool were to hash a stratum job ad nauseam and finally solve it, and then submit it, it would be rejected based on ntime (being some large time into the future). Stratum doesn't roll ntime and thus depends on the pool pushing new work requests.

Well, if you can't roll ntime (sounds like a major flaw to me), you'd just keep using the same one until you found the block. So if anything, it'd be too old. But Bitcoin itself doesn't care what ntime is as long as it is greater than or equal to the median of the last 10 blocks - in other words, the ntime the pool gives you the first time for each new block remains valid.

Quote from: slush on November 27, 2012, 05:53:28 AM

Quote from: Luke-Jr on November 26, 2012, 07:11:36 PM

Perhaps slush could clarify the current meaning

I don't understand what is unclear here.

a) clean_jobs=False means that previous jobs are still valid.
b) clean_jobs=True means that previous jobs become invalid.
c) If new work is received, miner automatically should use this job. There's no reason why to add a new flag to specify this, it is "by default". However miners can do whatever they want, because with or without a special flag, previous jobs are still valid.

KISS, please.

Ok, so that seems to agree with conman's interpretation somewhat. How do pools say "previous job remain valid for N more seconds"? It's unreasonable to expect pools to accept shares on previous jobs indefinitely, and also harmful to miners to discard shares across the change-over period. In short, there seems to be no possible way to implement the 2 minute expiration over stratum...

How do pools say "previous jobs shouldn't be used, but please submit them anyway"? This was an important fix added to getwork longpolling to correct pool-side statistics as well as avoid losing merged mining shares in some cases.

Quote from: hahahafr on November 27, 2012, 07:21:51 AM

I've read a certain number of posts from Kano speaking of these problems with Stratum now.

Kano's problem is just one of many...

Quote from: hahahafr on November 27, 2012, 07:21:51 AM

If I believe Kano,

Sounds like a pretty bad idea.

Quote from: hahahafr on November 27, 2012, 07:21:51 AM

(because GBT has too much stales)

This is either a myth or a cgminer bug.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: hahahafr on November 27, 2012, 07:21:51 AM

now is a good time to correct forgotten cases/issues by Slush, not in 2 months. Undecided

Actually I was thinking about reconnection pretty well, unfortunately I didn't find any proper solution yet. Resuming mining on another TCP connection goes against the KISS of Stratum and it requires advanced methods of load balancing.

That say, when you open two connections to my pool, you will most likely talk to completely different backends. Synchronizing them online so the second one will be able to accept and validate shares generated from another connection is really non-trivial issue...

hahahafr

hero member

Activity: 938

Merit: 501

Quote from: kano on November 27, 2012, 03:28:04 AM

Quote from: crazyates on November 27, 2012, 12:31:58 AM

Quote from: hahahafr on November 26, 2012, 11:45:48 PM

Quote from: crazyates on November 26, 2012, 11:23:04 PM

Ya my first several shares are usually rejects. I am mining over wifi, with about a dozen+ other computers on the network, so DCs are a fact of life. Still, I can live with 0.3% for now. Wink

Don't go further. This is the issue.

I'm not complaining. I know it's a problem, but one I sorta have to live with. Tongue

... only until the current stratum problem is resolved and we move on to 'discussing' the reconnect issue and fixing that

I've read a certain number of posts from Kano speaking of these problems with Stratum now. If I believe Kano, it looks like the solution are somewhat trivial to implement, by just modifying the specifications we would be good to go. In 2 months from now on, Stratum will be the de facto standard protocol (because GBT has too much stales), now is a good time to correct forgotten cases/issues by Slush, not in 2 months. Undecided

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: mdude77 on November 26, 2012, 08:51:51 PM

Just adding my 0.0016 BTC worth here..

Since p2pool has gone berserk, I have half my miners pointing at EMC, and half at Oz.

Oz is using stratum.
EMC is using GBT.

After about 12 hours, there were noticeably more rejects on EMC than on Oz. That's with using GBT, not stratum, on Oz.

Not sure if it means anything.

M

To give some numbers. After about 10 hours of mining, 2 identical rigs (3x7970 ~ 2GH/s):

oz:

Code:

 cgminer version 2.9.5 - Started: [2012-11-26 19:03:48]
--------------------------------------------------------------------------------
 (5s):2.002G (avg):1.997Gh/s | Q:1398  A:18114  R:14  HW:0  E:1296%  U:28.0/m
 TQ: 7  ST: 0  SS: 0  DW: 2574  NB: 75  LW: 20980  GF: 0  RF: 0  WU: 28.0
 Connected to stratum.ozco.in with stratum as user 
 Block: 048858edfdf0a45c5fe39cb2...  Started: [05:49:39]  Best share: 8.65K
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2787RPM | 666.9M/667.3Mh/s | A:6035 R:4 HW:0 U: 9.32/m I: 9
 GPU 1:  73.0C 2908RPM | 666.6M/667.5Mh/s | A:6040 R:5 HW:0 U: 9.32/m I: 9
 GPU 2:  73.0C 3197RPM | 662.3M/662.7Mh/s | A:6041 R:5 HW:0 U: 9.33/m I: 9
--------------------------------------------------------------------------------

eclipse:

Code:

 cgminer version 2.9.5 - Started: [2012-11-26 19:04:25]
--------------------------------------------------------------------------------
 (5s):1.958G (avg):1.956Gh/s | Q:1782  A:13009  R:53  HW:0  E:730%  U:20.1/m
 TQ: 0  ST: 11  SS: 0  DW: 3946  NB: 75  LW: 21963  GF: 0  RF: 0  WU: 27.5
 Connected to us1.eclipsemc.com with GBT as user 
 Block: 048858edfdf0a45c5fe39cb2...  Started: [05:49:41]  Best share: 572K
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2789RPM | 653.0M/655.3Mh/s | A:4348 R:21 HW:0 U:  6.71/m I: 9
 GPU 1:  73.0C 2606RPM | 654.5M/654.4Mh/s | A:4320 R:10 HW:0 U:  6.67/m I: 9
 GPU 2:  73.0C 2406RPM | 645.0M/646.7Mh/s | A:4341 R:22 HW:0 U:  6.70/m I: 9
--------------------------------------------------------------------------------

That's 0.07% rejects on Oz and 0.4% on Eclipse. Note that's fewer blocks submitted on eclipse because it is serving me somewhere between 1 and 2 difficulty shares, whereas Oz is 1 (even though I have it on var diff, 2gh must not be enough for auto to raise it).

M

slush

legendary

Activity: 1386

Merit: 1097

Quote from: Luke-Jr on November 26, 2012, 07:11:36 PM

Perhaps slush could clarify the current meaning

I don't understand what is unclear here.

a) clean_jobs=False means that previous jobs are still valid.
b) clean_jobs=True means that previous jobs become invalid.
c) If new work is received, miner automatically should use this job. There's no reason why to add a new flag to specify this, it is "by default". However miners can do whatever they want, because with or without a special flag, previous jobs are still valid.

KISS, please.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: crazyates on November 27, 2012, 12:31:58 AM

Quote from: hahahafr on November 26, 2012, 11:45:48 PM

Quote from: crazyates on November 26, 2012, 11:23:04 PM

Ya my first several shares are usually rejects. I am mining over wifi, with about a dozen+ other computers on the network, so DCs are a fact of life. Still, I can live with 0.3% for now. Wink

Don't go further. This is the issue.

I'm not complaining. I know it's a problem, but one I sorta have to live with. Tongue

... only until the current stratum problem is resolved and we move on to 'discussing' the reconnect issue and fixing that

optimator

sr. member

Activity: 351

Merit: 250

Quote from: Luke-Jr on November 26, 2012, 10:23:46 PM

Stratum jobs can be used infinitely, until the block is invalid or the pool expires the job. Unlike getwork, there is no 2³² nonce limit.

True. But there is a limit to ntime. If a pool were to hash a stratum job ad nauseam and finally solve it, and then submit it, it would be rejected based on ntime (being some large time into the future). Stratum doesn't roll ntime and thus depends on the pool pushing new work requests.

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: hahahafr on November 26, 2012, 11:45:48 PM

Quote from: crazyates on November 26, 2012, 11:23:04 PM

Ya my first several shares are usually rejects. I am mining over wifi, with about a dozen+ other computers on the network, so DCs are a fact of life. Still, I can live with 0.3% for now. Wink

Don't go further. This is the issue.

I'm not complaining. I know it's a problem, but one I sorta have to live with. Tongue

sharky112065

sr. member

Activity: 383

Merit: 250

Quote from: crazyates on November 26, 2012, 11:23:04 PM

Quote from: kano on November 26, 2012, 11:08:58 PM

Quote from: crazyates on November 26, 2012, 11:04:09 PM

Yep I'm on CGMiner 2.9.5, with stratum on Ozcoin. I set the diff to 2 with 1.5GH/s, and today I'm just under 0.3% rejects, which is actually pretty high. I'm usually around 0.1-0.2%. Cheesy

Those rejects are 99% likely to be either during connect while the difficulty corrects itself (directly related to the problem being discussed) or due to reconnects (i.e. if you lose pool connection)

The fix for the 2nd one (reconnects) is simply an enhancement ... that no doubt there will be few arguments about (when it gets in vogue Tongue

) since it is just an enhancement - no compatibility issue with the current implementation.

Ya my first several shares are usually rejects. I am mining over wifi, with about a dozen+ other computers on the network, so DCs are a fact of life. Still, I can live with 0.3% for now. Wink

LOL @ WIFI

hahahafr

hero member

Activity: 938

Merit: 501

Quote from: crazyates on November 26, 2012, 11:23:04 PM

Quote from: kano on November 26, 2012, 11:08:58 PM

Quote from: crazyates on November 26, 2012, 11:04:09 PM

Yep I'm on CGMiner 2.9.5, with stratum on Ozcoin. I set the diff to 2 with 1.5GH/s, and today I'm just under 0.3% rejects, which is actually pretty high. I'm usually around 0.1-0.2%. Cheesy

Those rejects are 99% likely to be either during connect while the difficulty corrects itself (directly related to the problem being discussed) or due to reconnects (i.e. if you lose pool connection)

The fix for the 2nd one (reconnects) is simply an enhancement ... that no doubt there will be few arguments about (when it gets in vogue Tongue

) since it is just an enhancement - no compatibility issue with the current implementation.

Ya my first several shares are usually rejects. I am mining over wifi, with about a dozen+ other computers on the network, so DCs are a fact of life. Still, I can live with 0.3% for now. Wink

Don't go further. This is the issue.

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: kano on November 26, 2012, 11:08:58 PM

Quote from: crazyates on November 26, 2012, 11:04:09 PM

Yep I'm on CGMiner 2.9.5, with stratum on Ozcoin. I set the diff to 2 with 1.5GH/s, and today I'm just under 0.3% rejects, which is actually pretty high. I'm usually around 0.1-0.2%. Cheesy

Those rejects are 99% likely to be either during connect while the difficulty corrects itself (directly related to the problem being discussed) or due to reconnects (i.e. if you lose pool connection)

The fix for the 2nd one (reconnects) is simply an enhancement ... that no doubt there will be few arguments about (when it gets in vogue Tongue

) since it is just an enhancement - no compatibility issue with the current implementation.

Ya my first several shares are usually rejects. I am mining over wifi, with about a dozen+ other computers on the network, so DCs are a fact of life. Still, I can live with 0.3% for now. Wink

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: crazyates on November 26, 2012, 11:04:09 PM

Yep I'm on CGMiner 2.9.5, with stratum on Ozcoin. I set the diff to 2 with 1.5GH/s, and today I'm just under 0.3% rejects, which is actually pretty high. I'm usually around 0.1-0.2%. Cheesy

Those rejects are 99% likely to be either during connect while the difficulty corrects itself (directly related to the problem being discussed) or due to reconnects (i.e. if you lose pool connection)

The fix for the 2nd one (reconnects) is simply an enhancement ... that no doubt there will be few arguments about (when it gets in vogue Tongue

) since it is just an enhancement - no compatibility issue with the current implementation.

crazyates

legendary

Activity: 952

Merit: 1000

Yep I'm on CGMiner 2.9.5, with stratum on Ozcoin. I set the diff to 2 with 1.5GH/s, and today I'm just under 0.3% rejects, which is actually pretty high. I'm usually around 0.1-0.2%. Cheesy

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