Bitcoin Forum
October 22, 2018, 09:58:06 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 462 ... 845 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5765855 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.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2674
Merit: 1144


Ruu \o/


View Profile WWW
November 26, 2012, 10:58:15 PM
 #8221

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.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
There are several different types of Bitcoin clients. Header-only clients like Bither trust that the majority of mining power is honest for the purposes of enforcing network rules such as the 21 million BTC limit. Full clients do not trust miners in this way.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1540245486
Hero Member
*
Offline Offline

Posts: 1540245486

View Profile Personal Message (Offline)

Ignore
1540245486
Reply with quote  #2

1540245486
Report to moderator
1540245486
Hero Member
*
Offline Offline

Posts: 1540245486

View Profile Personal Message (Offline)

Ignore
1540245486
Reply with quote  #2

1540245486
Report to moderator
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
November 26, 2012, 11:11:36 PM
 #8222

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

Activity: 2604
Merit: 1056


Linux since 1997 RedHat 4


View Profile
November 26, 2012, 11:17:33 PM
 #8223

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:
Quote
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 Smiley

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

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2674
Merit: 1144


Ruu \o/


View Profile WWW
November 26, 2012, 11:25:28 PM
 #8224

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?

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
Askit2
Hero Member
*****
Offline Offline

Activity: 986
Merit: 500


DIV - Your "Virtual Life" Secured and Decentralize


View Profile
November 26, 2012, 11:30:33 PM
 #8225

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:
Quote
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).

          ▄▄
        ▄█▀▀█▄
      ▄█▀ ▄▄ ▀█▄
      ▀ ▄████▄ ▀
   ▄▀ ▄ ▀████▀ ▄ ▀▄
 ▄▀ ▄███▄ ▀▀ ▄███▄ ▀▄
█  ███████  ███████  █
 ▀▄ ▀███▀ ▄▄ ▀███▀ ▄▀

   ▀▄ ▀ ▄████▄ ▀ ▄▀
      ▄ ▀████▀ ▄
      ▀█▄ ▀▀ ▄█▀
        ▀█▄▄█▀
          ▀▀
███████████████████████████████████████████████████████████████████
██████▀▀▀▀▀▀▀▀▀▀▀██████████▀▀▀▀▀████▀▀▀▀▀█████▀▀▀▀█████▀▀▀▀▀███████
██████            ▀████████     ████     █████    █████     ███████
██████     ▄▄▄▄▄    ▀██████     █████    ████      ████    ████████
██████     ██████▄    █████     █████    ▀██▀  ▄▄  ▀██▀    ████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████     █   ██   █     █████████
██████     █████▀    ██████     ███████       ████       ██████████
██████     ▀▀▀▀▀    ▄██████     ████████     ██████     ███████████
██████            ▄████████     ████████     ██████     ███████████
██████▄▄▄▄▄▄▄▄▄▄▄██████████▄▄▄▄▄█████████▄▄▄▄██████▄▄▄▄████████████
███████████████████████████████████████████████████████████████████
.DIWtoken.com.
▄██████████████████▄
███       ▀███████
███       █████████
███       █████████
███       █████████
███              ██
███   ▄▄▄▄▄▄▄▄   ███
███   ▄▄▄▄▄▄▄▄   ███
███              ███
███▄▄▄▄▄▄▄▄▄▄▄▄▄▄███
██████████████████▀

▄██████████████████▄
███████████▀ ███████
█████████▀   ███████
███████▀     ██▀ ███
███ ▀▀       █▄▄████
███          █▀▀▀▀██
███ ▄▄       ███████
██████▄     █▄ ▀███
█████████▄   ███▄███
███████████▄ ███████
▀██████████████████▀

▄██████████████████▄
████████████████████
███████████████▀▀ ██
█████████▀▀     ███
████▀▀     ▄█▀   ███
███▄    ▄██      ███
█████████▀      ▄██
█████████▄     ████
█████████████▄ ▄████
████████████████████
▀██████████████████▀
......SECURITY DECENTRALIZED...
Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
November 26, 2012, 11:32:50 PM
 #8226

Are you sure it's not an issue of share leakage?

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

Activity: 807
Merit: 500


View Profile
November 26, 2012, 11:36:42 PM
 #8227

I hate to interrupt all of this stratum discussion, but I am having crashes with GBT.  Running Fedora 15 with SDK 2.1 I think.  2.9.4 would exit with something like error code 11 (or 15 maybe?), and 2.9.5 segfaults.  I don't need GBT, so I should probably try to remember to try --fix-protocol instead of switching back to 2.8.7, but for now, I'm on 2.8.7 again.  I didn't report the issue with 2.9.4, but I suppose I should've.
ETA:  con, note that I wouldn't be against GBT being scrapped/removed from cgminer based on anything I've seen, but from a userbase standpoint, that might not be the option.  I'm only providing this most basic info in case it is helpful in some way.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2674
Merit: 1144


Ruu \o/


View Profile WWW
November 26, 2012, 11:40:41 PM
 #8228

I hate to interrupt all of this stratum discussion, but I am having crashes with GBT.  Running Fedora 15 with SDK 2.1 I think.  2.9.4 would exit with something like error code 11 (or 15 maybe?), and 2.9.5 segfaults.  I don't need GBT, so I should probably try to remember to try --fix-protocol instead of switching back to 2.8.7, but for now, I'm on 2.8.7 again.  I didn't report the issue with 2.9.4, but I suppose I should've.
ETA:  con, note that I wouldn't be against GBT being scrapped/removed from cgminer based on anything I've seen, but from a userbase standpoint, that might not be the option.  I'm only providing this most basic info in case it is helpful in some way.
Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full

And post the information from that please.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
Askit2
Hero Member
*****
Offline Offline

Activity: 986
Merit: 500


DIV - Your "Virtual Life" Secured and Decentralize


View Profile
November 26, 2012, 11:42:46 PM
 #8229

Are you sure it's not an issue of share leakage?

It's a tad hard to discern. It could be work that got misrouted to us1 pool....  Possibly there is an easy way to tell I haven't noticed in the past?
It happens from time to time. I do agree the other issue with stratum (disconncts lose shares) is a larger loss for me.

          ▄▄
        ▄█▀▀█▄
      ▄█▀ ▄▄ ▀█▄
      ▀ ▄████▄ ▀
   ▄▀ ▄ ▀████▀ ▄ ▀▄
 ▄▀ ▄███▄ ▀▀ ▄███▄ ▀▄
█  ███████  ███████  █
 ▀▄ ▀███▀ ▄▄ ▀███▀ ▄▀

   ▀▄ ▀ ▄████▄ ▀ ▄▀
      ▄ ▀████▀ ▄
      ▀█▄ ▀▀ ▄█▀
        ▀█▄▄█▀
          ▀▀
███████████████████████████████████████████████████████████████████
██████▀▀▀▀▀▀▀▀▀▀▀██████████▀▀▀▀▀████▀▀▀▀▀█████▀▀▀▀█████▀▀▀▀▀███████
██████            ▀████████     ████     █████    █████     ███████
██████     ▄▄▄▄▄    ▀██████     █████    ████      ████    ████████
██████     ██████▄    █████     █████    ▀██▀  ▄▄  ▀██▀    ████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████     █   ██   █     █████████
██████     █████▀    ██████     ███████       ████       ██████████
██████     ▀▀▀▀▀    ▄██████     ████████     ██████     ███████████
██████            ▄████████     ████████     ██████     ███████████
██████▄▄▄▄▄▄▄▄▄▄▄██████████▄▄▄▄▄█████████▄▄▄▄██████▄▄▄▄████████████
███████████████████████████████████████████████████████████████████
.DIWtoken.com.
▄██████████████████▄
███       ▀███████
███       █████████
███       █████████
███       █████████
███              ██
███   ▄▄▄▄▄▄▄▄   ███
███   ▄▄▄▄▄▄▄▄   ███
███              ███
███▄▄▄▄▄▄▄▄▄▄▄▄▄▄███
██████████████████▀

▄██████████████████▄
███████████▀ ███████
█████████▀   ███████
███████▀     ██▀ ███
███ ▀▀       █▄▄████
███          █▀▀▀▀██
███ ▄▄       ███████
██████▄     █▄ ▀███
█████████▄   ███▄███
███████████▄ ███████
▀██████████████████▀

▄██████████████████▄
████████████████████
███████████████▀▀ ██
█████████▀▀     ███
████▀▀     ▄█▀   ███
███▄    ▄██      ███
█████████▀      ▄██
█████████▄     ████
█████████████▄ ▄████
████████████████████
▀██████████████████▀
......SECURITY DECENTRALIZED...
TheHarbinger
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


Why is it so damn hot in here?


View Profile
November 26, 2012, 11:43:25 PM
 #8230

I have learned quite a bit since starting with BitCoin, I will try to sum it all up for anyone who doesn't want to read every post in these forums.

Luke Jr. is never wrong.
Inaba is never wrong.
RealSolid is never wrong.

I can only wait in eager anticipation for the day when EMC adds SC mining, with SC mining added to BFG miner.  Then we will truly be living in a utopia!

12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
November 26, 2012, 11:51:56 PM
 #8231

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?
You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?
That sounds highly unlikely, and unrelated. What kind of a reject?

The00Dustin
Hero Member
*****
Offline Offline

Activity: 807
Merit: 500


View Profile
November 27, 2012, 12:00:12 AM
 #8232

Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full

And post the information from that please.
I'm getting "No stack."  I assume that makes it obvious I've never done this before...

ETA:
Code:
cat /usr/src/cgminer-2.9.5/Makefile | grep CFLAGS\ =
CFLAGS = -I/usr/src/ati-stream-sdk-v2.1-lnx64/include -g
P_Shep
Legendary
*
Offline Offline

Activity: 1176
Merit: 1000


View Profile
November 27, 2012, 12:01:16 AM
 #8233

Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full

And post the information from that please.
I'm getting "No stack."  I assume that makes it obvious I've never done this before...

That means you have to go to IHOP.
The00Dustin
Hero Member
*****
Offline Offline

Activity: 807
Merit: 500


View Profile
November 27, 2012, 12:03:18 AM
 #8234


That mean you have to go to IHOP.
1) I don't like hopping
2) I don't like pancakes
3) Prayer takes so much time
4) I assume I detected your humor, but if I did not, or if IHOP means something else as well, feel free to tell.  Tongue
P_Shep
Legendary
*
Offline Offline

Activity: 1176
Merit: 1000


View Profile
November 27, 2012, 12:05:17 AM
 #8235

Askit2
Hero Member
*****
Offline Offline

Activity: 986
Merit: 500


DIV - Your "Virtual Life" Secured and Decentralize


View Profile
November 27, 2012, 12:14:54 AM
 #8236

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?
You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?
That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!

          ▄▄
        ▄█▀▀█▄
      ▄█▀ ▄▄ ▀█▄
      ▀ ▄████▄ ▀
   ▄▀ ▄ ▀████▀ ▄ ▀▄
 ▄▀ ▄███▄ ▀▀ ▄███▄ ▀▄
█  ███████  ███████  █
 ▀▄ ▀███▀ ▄▄ ▀███▀ ▄▀

   ▀▄ ▀ ▄████▄ ▀ ▄▀
      ▄ ▀████▀ ▄
      ▀█▄ ▀▀ ▄█▀
        ▀█▄▄█▀
          ▀▀
███████████████████████████████████████████████████████████████████
██████▀▀▀▀▀▀▀▀▀▀▀██████████▀▀▀▀▀████▀▀▀▀▀█████▀▀▀▀█████▀▀▀▀▀███████
██████            ▀████████     ████     █████    █████     ███████
██████     ▄▄▄▄▄    ▀██████     █████    ████      ████    ████████
██████     ██████▄    █████     █████    ▀██▀  ▄▄  ▀██▀    ████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████     █   ██   █     █████████
██████     █████▀    ██████     ███████       ████       ██████████
██████     ▀▀▀▀▀    ▄██████     ████████     ██████     ███████████
██████            ▄████████     ████████     ██████     ███████████
██████▄▄▄▄▄▄▄▄▄▄▄██████████▄▄▄▄▄█████████▄▄▄▄██████▄▄▄▄████████████
███████████████████████████████████████████████████████████████████
.DIWtoken.com.
▄██████████████████▄
███       ▀███████
███       █████████
███       █████████
███       █████████
███              ██
███   ▄▄▄▄▄▄▄▄   ███
███   ▄▄▄▄▄▄▄▄   ███
███              ███
███▄▄▄▄▄▄▄▄▄▄▄▄▄▄███
██████████████████▀

▄██████████████████▄
███████████▀ ███████
█████████▀   ███████
███████▀     ██▀ ███
███ ▀▀       █▄▄████
███          █▀▀▀▀██
███ ▄▄       ███████
██████▄     █▄ ▀███
█████████▄   ███▄███
███████████▄ ███████
▀██████████████████▀

▄██████████████████▄
████████████████████
███████████████▀▀ ██
█████████▀▀     ███
████▀▀     ▄█▀   ███
███▄    ▄██      ███
█████████▀      ▄██
█████████▄     ████
█████████████▄ ▄████
████████████████████
▀██████████████████▀
......SECURITY DECENTRALIZED...
kano
Legendary
*
Offline Offline

Activity: 2604
Merit: 1056


Linux since 1997 RedHat 4


View Profile
November 27, 2012, 12:22:33 AM
 #8237

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?
You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?
That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!
Luke-Jr thank you for yet again pointing out why people who use your miner get less shares Tongue (and shouldn't be using it)
Yeah processing previous block work after an LP ... right ... ... ...

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
November 27, 2012, 12:39:17 AM
 #8238

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?
You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?
That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!
Ok, I missed that somehow. "unknown-work" can only occur if one of these 3 cases:
  • a block was found (which you ruled out)
  • the miner submitted it after it expired (120 seconds on EMC; new work is delivered at least every 96 seconds)
  • the user extranonce1 was lost (only possible if you reconnected)
I'm pretty sure cgminer discards all work/shares in the last case (reconnection), so that means it either:
  • was working on a job 23 seconds after it had been replaced (this is sufficient for as low as 200 Mh/s)
  • was working on a job 21 seconds after it had been replaced AND took over 2 seconds to submit it to the pool
This makes sense, since cgminer is failing to move on to new jobs as they come in.

mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
November 27, 2012, 12:51:51 AM
 #8239

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

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
Askit2
Hero Member
*****
Offline Offline

Activity: 986
Merit: 500


DIV - Your "Virtual Life" Secured and Decentralize


View Profile
November 27, 2012, 12:58:56 AM
 #8240

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?
You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?
That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!
Ok, I missed that somehow. "unknown-work" can only occur if one of these 3 cases:
  • a block was found (which you ruled out)
  • the miner submitted it after it expired (120 seconds on EMC; new work is delivered at least every 96 seconds)
  • the user extranonce1 was lost (only possible if you reconnected)
I'm pretty sure cgminer discards all work/shares in the last case (reconnection), so that means it either:
  • was working on a job 23 seconds after it had been replaced (this is sufficient for as low as 200 Mh/s)
  • was working on a job 21 seconds after it had been replaced AND took over 2 seconds to submit it to the pool
This makes sense, since cgminer is failing to move on to new jobs as they come in.

So a BFL single running 864mhash bitstream in your example would need to work on the work for 114.8 seconds to go over. Interesting to know.
I didn't change scan time for stratum but the settings of scan time at 115 had worked fine on get work.

I will bump it down but since not every 120 seconds has this happening I would assume it is something else. The ping to Eclipse is 76ms right now. It can vary but assuming I got my work at 96 seconds add .5 for significant delays, 5.16s for single to process work I get 101.66 seconds. Leaving me 18.34 seconds to submit.....

          ▄▄
        ▄█▀▀█▄
      ▄█▀ ▄▄ ▀█▄
      ▀ ▄████▄ ▀
   ▄▀ ▄ ▀████▀ ▄ ▀▄
 ▄▀ ▄███▄ ▀▀ ▄███▄ ▀▄
█  ███████  ███████  █
 ▀▄ ▀███▀ ▄▄ ▀███▀ ▄▀

   ▀▄ ▀ ▄████▄ ▀ ▄▀
      ▄ ▀████▀ ▄
      ▀█▄ ▀▀ ▄█▀
        ▀█▄▄█▀
          ▀▀
███████████████████████████████████████████████████████████████████
██████▀▀▀▀▀▀▀▀▀▀▀██████████▀▀▀▀▀████▀▀▀▀▀█████▀▀▀▀█████▀▀▀▀▀███████
██████            ▀████████     ████     █████    █████     ███████
██████     ▄▄▄▄▄    ▀██████     █████    ████      ████    ████████
██████     ██████▄    █████     █████    ▀██▀  ▄▄  ▀██▀    ████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████     █   ██   █     █████████
██████     █████▀    ██████     ███████       ████       ██████████
██████     ▀▀▀▀▀    ▄██████     ████████     ██████     ███████████
██████            ▄████████     ████████     ██████     ███████████
██████▄▄▄▄▄▄▄▄▄▄▄██████████▄▄▄▄▄█████████▄▄▄▄██████▄▄▄▄████████████
███████████████████████████████████████████████████████████████████
.DIWtoken.com.
▄██████████████████▄
███       ▀███████
███       █████████
███       █████████
███       █████████
███              ██
███   ▄▄▄▄▄▄▄▄   ███
███   ▄▄▄▄▄▄▄▄   ███
███              ███
███▄▄▄▄▄▄▄▄▄▄▄▄▄▄███
██████████████████▀

▄██████████████████▄
███████████▀ ███████
█████████▀   ███████
███████▀     ██▀ ███
███ ▀▀       █▄▄████
███          █▀▀▀▀██
███ ▄▄       ███████
██████▄     █▄ ▀███
█████████▄   ███▄███
███████████▄ ███████
▀██████████████████▀

▄██████████████████▄
████████████████████
███████████████▀▀ ██
█████████▀▀     ███
████▀▀     ▄█▀   ███
███▄    ▄██      ███
█████████▀      ▄██
█████████▄     ████
█████████████▄ ▄████
████████████████████
▀██████████████████▀
......SECURITY DECENTRALIZED...
Pages: « 1 ... 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 462 ... 845 »
  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!