Bitcoin Forum
December 09, 2016, 03:55:25 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 [411] 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4824881 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
awatson824
Member
**
Offline Offline

Activity: 61



View Profile
November 25, 2012, 11:10:38 PM
 #8201

Ckolivas, is it my computer or graphics card that is giving me 46 stales in 8 hours?
Not being mean just asking cause I don't get it. :/

How could he possibly answer that given that you gave so little information about your setup. Try giving him/us more details. What pool? What version of Cgminer? What is your hardware setup? ...

Note: if you are on p2pool there was a recent hard fork and issues should stabilize over time.


BtcGuild, latest version and I tried with my 1 HD Radeon 6670

And how many accepts? What percentage is your rejects?
I got about 800 accepts and 40-60 stales

My new PPLNS litecoin pool! www.ltcgoldmine.com !!
1481298925
Hero Member
*
Offline Offline

Posts: 1481298925

View Profile Personal Message (Offline)

Ignore
1481298925
Reply with quote  #2

1481298925
Report to moderator
1481298925
Hero Member
*
Offline Offline

Posts: 1481298925

View Profile Personal Message (Offline)

Ignore
1481298925
Reply with quote  #2

1481298925
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481298925
Hero Member
*
Offline Offline

Posts: 1481298925

View Profile Personal Message (Offline)

Ignore
1481298925
Reply with quote  #2

1481298925
Report to moderator
1481298925
Hero Member
*
Offline Offline

Posts: 1481298925

View Profile Personal Message (Offline)

Ignore
1481298925
Reply with quote  #2

1481298925
Report to moderator
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
November 25, 2012, 11:11:25 PM
 #8202

...
D. Diff falls in the round-trip window period as cgminer has discarded a share that would now be adequate as cgminer is not aware of the new diff
...
Scenario D:
cgminer can't do anything about it, and this work is lost. Any decrease of diff by a pool can elicit this, and the more often the difficulty is lowered, the more shares are lost. No rejects are induced.
In fact there is something that may be done and it would prevent any share being lost if the difficulty changes are bounded.
Keep shares from the last seconds (this window should probably be a tunable) that satisfy difficulty >= target / max_retarget_factor where max_retarget_factor is either a constant, user-parameter, provided by pool, ...
If there is a decrease in diff, submit the shares that satisfy it.

It's a kludge but shouldn't it work?

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
November 25, 2012, 11:16:24 PM
 #8203

ckolivas, maybe you can now simplify the vardiff code by storing currently known difficulty with the job which has been notified by the server? Practically it may work as if difficulty is a part of the notify message itself. This will still work with existing pools, code for managing it is much simpler and solves some uncertainity in edge cases...

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 25, 2012, 11:17:26 PM
 #8204

ckolivas, maybe you can now simplify the vardiff code by storing currently known difficulty with the job which has been notified by the server? Practically it may work as if difficulty is a part of the notify message itself. This will still work with existing pools, code for managing it is much simpler and solves some uncertainity in edge cases...
I already do that.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
November 26, 2012, 12:05:18 AM
 #8205

There are 4 distinctly different scenarios with changing diff separate from work.
A. Diff rises before cgminer submits lower diff share and cgminer is aware of it
B. Diff falls before cgminer submits now adequate diff share and cgminer is aware of it
C. Diff rises in the round-trip window period as cgminer has already submitted a share below difficulty and cgminer is not aware of the new diff
D. Diff falls in the round-trip window period as cgminer has discarded a share that would now be adequate as cgminer is not aware of the new diff

If I understand it correctly, these scenarios cannot happen after the change in set_difficulty meaning, because difficulty is always received before the job (there cannot be any race condition because both messages are pipelined over the same socket). Am I correct?

That say, I feel that there's some misunderstanding and I'd like to clarify that we all work with the same information.

Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
November 26, 2012, 12:07:43 AM
 #8206

Ok... I think maybe part of the fundamental problem here is that Slush's view is that all work sent out to a miner is related to work that has come before it (and work that will be sent after it), whereas, at least in my view, work that is sent out is discrete; it's completely immaterial what's come before or what is going to come after.  Correct me if I'm wrong here, but it seems that this is the root of the issue and why difficulty is not tied to work in Stratum.  

Maybe if you (Slush) can explain why a work packet being sent to a miner needs to be related to another work packet (either being sent to the same miner or someone else) as opposed to being discrete?  I'm just not seeing why work at difficulty X needs to be related to work at difficulty X + 1.  The miner is assigned work at difficulty X.  If they do the work, they should be rewarded for that work, regardless of the fact that difficulty changed since the work was sent out... they still did the work!  So rejecting the work because the pool arbitrarily decided to change the difficulty on the miner is rude if not outright dishonest.

Rejecting shares because difficulty changes AFTER the fact could easily be exploited by a malicious pool and amount to a very, very significant income stream at a miners expense.  For example, say I setup a malicious pool... every 10th share, I code the pool to raise the difficulty (then reduce it a short while later), thereby "rejecting" 1 out of every 10 shares that miner sends back... but I keep those shares and assign them to another user or the pool itself, etc... because those shares are still valid.  Now the pool gets 10% of the shares a user sends, the user thinks "crap, I'm getting 10% rejects because of my hashrate" or whatever reason you want to assign to it and it looks totally legitimate.  Now reduce that to .1% and spread that across 100 TH and 2000 miners... the miners won't notice such a small amount, but now the pool op gets the equivalent 100 GH/s for free and no one is the wiser.  This is what the Stratum protocol allows as designed, and if I'm wrong about this please let me know and explain why this can't be done?  This is also why difficulty needs to be tied to the work, so that work performed is never rejected because the pool decided to change the rules after the fact.

A more extreme example would be:  Pool keeps increasing the difficulty every set interval, causing all shares to be discarded by a miner until a valid block share is found.  Now that miner gets credit for 1 share, even though they should have sent 20,000 shares.  Yeah, this is unrealistic, but it illustrates the point that it's possible to exploit the protocol to the detriment of the miner.

I will be happy if I'm wrong and if someone can point out where I'm mistaken.  This is really my only major problem with Stratum at the moment, everything else is fairly minor in comparison.  I apologize if my tone appears aggressive towards you, Slush.  It was not intended to be, beyond my minor irritation with the way Stratum was rolled out... and that irritation is minor and not worth complaining about.  My "bashing" of Stratum is because the problem has been beat to death and you basically ignored anyone who disagreed with the work/difficulty being uncoupled.  Regardless, moving on to the solution you mentioned:

How does it address the following scenario:

Miner is given work at difficulty 2.  Miner begins processing work at difficulty 2 and finds a valid share... while processing the work Stratum sends mining.set_difficulty 3.  

What happens to that share found at difficulty 2, which was valid at the time it was issued?  The miner did the work based on the rules it was given, but the rules got changed after it already agreed to the work.



If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
November 26, 2012, 12:14:01 AM
 #8207

Miner is given work at difficulty 2.  Miner begins processing work at difficulty 2 and finds a valid share... while processing the work Stratum sends mining.set_difficulty 3.  

What happens to that share found at difficulty 2, which was valid at the time it was issued?  The miner did the work based on the rules it was given, but the rules got changed after it already agreed to the work.

What exactly is unclear on the sentence (from stratum docs):

Quote
This means that difficulty 2 will be applied to every next job received from the server.

If pool sends new difficulty, but then receive the solution from previous job, user must be credited for previous difficulty.

Edit: Although I don't fully understand these scenarios described by you, I think understanding of ^^ will give you the answer to some points. Also, if I understand some of your questions, Stratum proposal doesn't target scenarios with poolop cheating with counting shares.

Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
November 26, 2012, 12:18:16 AM
 #8208

Ok, if that's the case then that solves the issue.  Conman, does that resolve the rapid difficulty change issue with EMC then if that particular method is implemented to handle difficulty from the Stratum protocol side of things?

Quote
Edit: Although I don't fully understand these scenarios described by you, I think understanding of ^^ will give you the answer to some points. Also, if I understand some of your questions, Stratum proposal doesn't target scenarios with poolop cheating with counting shares.

It needs to... not to keep pool ops honest so much as to allow miners to verify that what they THINK is happening is really happening.  It's about empowering the miners, not policing the pool ops.

Quote
No, this still does not address D.

Is this relevant though?  I'm not sure I'm comfortable with this, as it flips the exploit over to the miners side (although it has much less of an impact).  I don't want to issue difficulty 32 shares, have them reduce their hashrate while they save up a bunch of shares until their difficulty reduces then submit them all as valid.  Again, we go back to difficulty being tied to the work sent out.  Allowing it to "leak" out to other work/difficulty relationships is not the correct way to go about it IMHO.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 26, 2012, 12:29:41 AM
 #8209

Ok, if that's the case then that solves the issue.  Conman, does that resolve the rapid difficulty change issue with EMC then if that particular method is implemented to handle difficulty from the Stratum protocol side of things?
For scenario A, if the old diff applies to work given out prior to the diff change it's almost the same as tying it with the work, and is how cgminer currently manages difficulty already for rising diff. Scenario C will sort itself out as well. So this works for me.

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

There is still the potential for lost opportunity in scenario D, and this would be no different if difficulty is tied with work or not, with gbt or stratum, as every window lost is the time of a one way trip from the server to the miner. While small, if done often it would start to add up. Thus it would still be prudent to minimise the diff changes to avoid this.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
November 26, 2012, 12:50:07 AM
 #8210

For scenario B, the old difficulty would still apply to work for that discrete issue of work.  I definitely do not want to create a potential scenario where it could be exploited by forcing a difficulty change.  One way can be exploited by pool ops (not accepting work once difficulty changed), one way can be exploited by miners (accepting work for higher difficulty work as valid once work drops) and one way (tying difficulty to work) can not be exploited by either, and this seems the most sane way to handle it. 


If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
optimator
Sr. Member
****
Offline Offline

Activity: 351



View Profile WWW
November 26, 2012, 12:59:58 AM
 #8211


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.

mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
November 26, 2012, 01:44:53 AM
 #8212

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? Smiley

Regards,

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 26, 2012, 01:47:19 AM
 #8213

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? Smiley
Not much point when we'll all be mining difficulties in the 10s to 100s soon.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
DrHaribo
Legendary
*
Online Online

Activity: 1960


Bitminter.com Operator


View Profile WWW
November 26, 2012, 06:37:47 AM
 #8214

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

! :-)

That did it, thanks!

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
November 26, 2012, 06:19:21 PM
 #8215

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
Legendary
*
Offline Offline

Activity: 2100



View Profile
November 26, 2012, 06:25:13 PM
 #8216

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
Sr. Member
****
Offline Offline

Activity: 422



View Profile
November 26, 2012, 07:26:09 PM
 #8217

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
Member
**
Offline Offline

Activity: 78


View Profile
November 26, 2012, 08:32:14 PM
 #8218

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

Well done! Smiley

--
Bye
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 26, 2012, 08:47:16 PM
 #8219

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
November 26, 2012, 09:06:44 PM
 #8220

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

Pages: « 1 ... 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 [411] 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!