Miner stats on ethermine.org show 1 stale share, but no stale shares on console output of ethminer

jmsjrjmsjr Member Posts: 42
I have just resumed mining on asia1.ethermine.org.

After about 40 minutes, one of my workers ( I only have 2 workers ) shows up with 1 stale share .. but the console output from ethminer from that worker does NOT show any stale share at all !!! It shows A35+0:R0:F0 ( 35 accepted, 0 stales, 0 rejects, 0 fails ).

How can that be???

Comments

  • jmsjrjmsjr Member Posts: 42
    edited March 13
    jmsjr said:

    I have just resumed mining on asia1.ethermine.org.

    After about 40 minutes, one of my workers ( I only have 2 workers ) shows up with 1 stale share .. but the console output from ethminer from that worker does NOT show any stale share at all !!! It shows A35+0:R0:F0 ( 35 accepted, 0 stales, 0 rejects, 0 fails ).

    How can that be???

    OK .. Eventually, the console output of the worker matched the stats on ethermine.org so that the ethminer output now shows A44+1:R+0:F+0 ( 44 accepted , 1 stale )

    ...but how the heck did ethermine.org know *in advance* that I have a stale share ??
  • jmsjrjmsjr Member Posts: 42
    Happened again.

    The image below shows 4 stale shares:



    .. and my ethminer output for each worker shows a total of 3 stale shares:

    ℹ 23:18:28|stratum | Received new job #ab17122b… from asia1.ethermine.org cl 23:18:28|cl-0 | Switch time 29 ms. m 23:18:32|ethminer| Speed 26.78 Mh/s gpu/0 26.78 49C 48% [A24+1:R0+0:F0] Time: 01:03 m 23:18:37|ethminer| Speed 26.78 Mh/s gpu/0 26.78 49C 48% [A24+1:R0+0:F0] Time: 01:03 ℹ 23:18:38|stratum | Received new job #d4da77b9… from asia1.ethermine.org cl 23:18:38|cl-0 | Switch time 34 ms.

    ℹ 23:19:12|stratum | Received new job #ae9600e3… from asia1.ethermine.org cu 23:19:12|cuda-1 | Switch time 2 ms. cu 23:19:12|cuda-0 | Switch time 6 ms. m 23:19:13|ethminer| Speed 56.89 Mh/s gpu/0 28.44 50C 45% 90W gpu/1 28.44 55C 75% 99W [A48+2:R0+0:F0] Time: 01:04 m 23:19:18|ethminer| Speed 56.70 Mh/s gpu/0 28.35 50C 45% 90W gpu/1 28.35 55C 75% 101W [A48+2:R0+0:F0] Time: 01:04 m 23:19:23|ethminer| Speed 56.90 Mh/s gpu/0 28.43 50C 45% 90W gpu/1 28.47 55C 75% 101W [A48+2:R0+0:F0] Time: 01:04 m 23:19:28|ethminer| Speed 57.15 Mh/s gpu/0 28.58 50C 45% 90W gpu/1 28.58 55C 75% 99W [A48+2:R0+0:F0] Time: 01:04 m 23:19:33|ethminer| Speed 57.15 Mh/s gpu/0 28.58 50C 45% 90W gpu/1 28.58 55C 75% 99W [A48+2:R0+0:F0] Time: 01:04

    Again, how did ethermine.org decide that I have 4 stale shares when my output only shows 3 ?
  • kondratovich1kondratovich1 Member Posts: 18
    Miner shows stale shares detected locally. When share is submitted after new job received. But due to connectivity latency, job can be received with delay. On pool job is changed, on miner is not. Pool return true false based on validity. On stale share pool returns true.
  • jmsjrjmsjr Member Posts: 42

    Miner shows stale shares detected locally. When share is submitted after new job received. But due to connectivity latency, job can be received with delay. On pool job is changed, on miner is not. Pool return true false based on validity. On stale share pool returns true.

    OK. Thanks. That's what I was assuming too.
    So the protocol is not totally correct then ... I am assuming that the protocol prevent this from happening .. that when the miner ( claymore / ethminer ) submits a non-stale share and it was accepted ...that IT IS non-stale.

    But I guess what you said answers my other question that I had before but never asked.. how does a miner ( claymore / ethminer ) know that a share being submitted is stale or not ? The console output from ethminer actually says when it is submitting a stale share.

    Makes sense now.


  • kondratovich1kondratovich1 Member Posts: 18
    From the point of miner, stale share is share that was not send yet after new job received.
    Actually, miner can send stale shares (calculated after new job received) by some reason - there is configuration for this.
  • rigproxyrigproxy Member Posts: 26
    When you submit a work (=share), the server gets it and says "ok thanks" to your miner as fast as possible. Ater that, it really verifies if it should be or not considered as a valid/stale share and your miner does not have this info.

    A stale received 1ms before could have been a valid share. But if it is a stale share, the server decided so, and you can't do anything except trying to bring them faster.
    For that, you need a lower latency which is the purpose of http://www.rigproxy.com
    You may contact me (admin |at| rigproxy |dot| com) if help is required.
Sign In or Register to comment.