Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 104. (Read 499709 times)

"My Earning" in the "Block Stats" tab are erroneous for me. In the BTC section it looks as if the displayed values are doubled, and in NMC looks fine, but one value (block 59207) is way lower than it should be.

Send me your account name and I can look at it.

I've mined 23 blocks so far (started on 6/2).

How many blocks have you mined in?  It takes about 7 blocks to "fill" the DGM "capacitor" - which means it takes about 7 blocks before you start seeing the equivalent proportional payout from DGM (then it takes about 7 blocks to wind down, once you stop mining).

When I compare my reward to the percentage of shares I've submitted, it looks like I'm getting 10% less.

It's probably a DGM thing, but does somebody have a simple explanation for where the extra 10% goes?

For example, for the last round:

Total Shares = 4903431
My Shares = 19447

"Your reward is 0.17833900 BTC."

(what I'd expect)
19447 / 4903431 = 0.00396599 * 50 = 0.19829950

(the difference, which is about 10%)
0.19829950 - 0.17833900 = 0.01996050

OK, without the --failover-only option there's indeed some occasional delay in the route that can cause a switch to the backup pool; running mtr for a while suggests that (so that part seems to be related to my ISP).

With the --failover-only option it's more stable against short delays, so it happens less frequent, only every other day or so, so not dramatic enough to jump to conclusions. I'll keep an eye on it and will collect some logging data (haven't done that yet, I didn't want to clutter the SD card on my RaspberryPi) before reporting back.

Hmm, yeah you don't seem to have any strange or misbehaving routes.

How often is this happening?  Do you happen to have a log of the times it's happened in the past?

And here's the mtr report:

HOST: wogaut                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.254              0.0%    50    1.6   1.6   1.5   2.4   0.2
  2.|-- 99-63-172-2.lightspeed.mi 80.0%    50   23.3  23.5  22.2  25.5   1.0
  3.|-- 71.144.192.62             92.0%    50   36.5  26.6  22.6  36.5   6.6
  4.|-- 71.144.192.126            90.0%    50   23.0  22.9  22.6  23.4   0.3
  5.|-- 71.144.192.120            98.0%    50   23.5  23.5  23.5  23.5   0.0
  6.|-- 12.83.79.141               0.0%    50   22.6  22.5  21.7  23.9   0.4
  7.|-- cgcil03jt.ip.att.net       0.0%    50   24.6  32.8  23.9 116.7  20.9
  8.|-- 192.205.37.178             0.0%    50   25.4  25.3  24.5  28.1   0.6
    |  `|-- 192.205.37.174
    |   |-- 154.54.12.85
  9.|-- te0-4-0-1.ccr21.ord01.atl  0.0%    50   25.9  26.2  24.6  39.6   2.5
 10.|-- te0-1-0-3.ccr21.mci01.atl  0.0%    50   49.8  49.8  48.6  58.6   1.4
 11.|-- te0-2-0-0.mpd22.mci01.atl  0.0%    50   50.1  49.9  48.9  53.4   0.7
 12.|-- everest.demarc.cogentco.c  0.0%    50   50.0  49.7  48.5  61.6   1.8
 13.|-- 69.30.209.1                0.0%    50   49.8  48.1  47.1  50.3   1.0
 14.|-- us1.eclipsemc.com          0.0%    50   47.2  47.7  46.7  49.8   0.8

IMO the loss values reported above are no reason for concern, I would think they are a result of rate limiting, since there's 0% loss down the chain.

Here's my traceroute output:

traceroute to us2.eclipsemc.com (208.110.68.114), 30 hops max, 40 byte packets using UDP
 1  192.168.1.254 (192.168.1.254)  1.885 ms   1.596 ms   1.338 ms
 2  99-63-172-2.lightspeed.milwwi.sbcglobal.net (99.63.172.2)  23.900 ms   24.105 ms   27.475 ms
 3  * * *
 4  * * *
 5  * * *
 6  12.83.79.141 (12.83.79.141)  22.846 ms   22.825 ms   21.674 ms
 7  cgcil03jt.ip.att.net (12.122.84.93)  24.986 ms   24.823 ms   25.978 ms
 8  192.205.37.178 (192.205.37.178)  27.058 ms   26.021 ms te0-2-0-2.ccr22.ord03.atlas.cogentco.com (154.54.12.85)  24.909 ms
 9  te0-5-0-7.ccr22.ord01.atlas.cogentco.com (154.54.44.165)  27.581 ms te0-5-0-1.ccr22.ord01.atlas.cogentco.com (154.54.43.233)  26.491 ms te0-0-0-1.ccr22.ord01.atlas.cogentco.com (154.54.1.97)  26.200 ms
10  te0-4-0-5.ccr21.mci01.atlas.cogentco.com (154.54.45.145)  48.498 ms te0-5-0-1.mpd22.ord01.atlas.cogentco.com (154.54.44.177)  26.073 ms te0-1-0-3.ccr22.mci01.atlas.cogentco.com (154.54.5.173)  49.963 ms
11  te0-2-0-0.mpd22.mci01.atlas.cogentco.com (154.54.30.158)  49.552 ms te0-1-0-0.mpd22.mci01.atlas.cogentco.com (154.54.30.154)  50.029 ms   48.918 ms
12  everest.demarc.cogentco.com (38.104.86.2)  51.064 ms   51.869 ms   50.723 ms
13  69.30.209.1 (69.30.209.1)  48.612 ms   48.400 ms   47.694 ms
14  us1.eclipsemc.com (208.110.68.114)  49.585 ms   48.473 ms   48.097 ms

Can you try running a traceroute to the server and see if you are dropping packets anywhere?  Something like ping plotter would be really helpful in diagnosing it as well.

But starting with a post of your traceroute might reveal some clues.

It seems I am experiencing time lags with Eclipse; cgminer even tries to get work from the failover pool (if I don't set --failover-only it says primary pool is lagging and tries to fetches work from secondary pool).

Any idea, or things I should look for?

Edit: I checked into possible issues and noticed that some users described a timeout with cgminer 2.3
It's sort of similar, but I'm running cgminer 2.4.1-9 under Linux. It's running great for a while and than suddenly there's some wait time, and then it recovers. No idea. The network seems ok though.

Wow, I just got my two BFL Singles yesterday and started mining on Eclipse and we've already had 8 blocks found and it hasn't even been 24 hours yet.

looks like something's up again.

edit: seems to be working fine again.

No need to apologize, imo. Thanks for fixing.

Seems to be a memory leak in Bitcoind... it will be back up in a minute.  Sorry! 

Yup, one of my workers is doing fine, the other is on backup pool.

Something is wrong with the pool!

I know what you're saying and I agree, but it does have meaning in absolute terms of time.  At a given hashrate it's going to take X amount of hours to solve Y amount of shares... so 825% for Deepbit means far less time than 400% at EMC -> I'll take Deepbit's time factor

Don't forget that the number by itself doesn't mean much, it's shares/difficulty that actually has meaning.
... and that the record I've seen so far that I've mentioned before is 8.25 on deepbit (825%)

Lifetime max was around 10 million... it will show you the max under the graphs section.