[1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration!

[Inaba]

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.

[wogaut]

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.

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

[wogaut]

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.

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.

[Inaba]

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?

[wogaut]

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?

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.

[dave3]

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

[Inaba]

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

[dave3]

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

[Inaba]

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

[cyberlync]

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

[Inaba]

Ah.. yeah looks like I broke it adding the PPS stuff in there.

I'll have it fixed shortly... yes everything is indeed being doubled.

[BR0KK]

something's wrong with  us and eu servers?

Had some connection issues but I'm still mining over us1 (backup server)

[Inaba]

No, everything seems fine.  What problems are you having?

[BR0KK]

hm seems to be some connection hiccups that i have on both servers? Nothing to bad so don't worry

This could just be my setup. That thing might need a restart (mac mini + parallels + win7: and many updates to go ) or my crappy internet connection thats failing from now to then.....

[Inaba]

The SMS Gateway is having issues, which is beyond my control.  So SMS messages are being delayed or getting completely lost best I can tell.  I will continue to follow up with the gateway provider, but my hands are somewhat tied at the moment. 

[Inaba]

Between Dave and a couple other people, I was able to finally track down the bug that was causing it to appear that people were receiving 10% less (roughly) per block in payment than they should when measured against proportional.

It turns out the PPS shares were not being counted towards the block totals, and since PPS makes up roughly 10% of the hashrate, total block shares were being under-reported by that amount.  

I've changed the code going forward to account for the PPS shares and retroactively re-calculated all the blocks from block 1001 to current to report the correct number of shares (I knew there was a reason I store all that extra data about users and blocks!).  So block stats should now be accurate, but this has the unfortunate side effect of making the luck factor drop by about 3%  

Things make a lot more sense now, as to our luck factor and why blocks seemed to be taking longer than they should, given the amount of shares vs. hashrate.  Missing 10% of your hashrate and shares in the calculation is not an insignificant amount.  

Anyway, the bottom line is, stats should be correct.  No one was underpaid, as the share calculations were taken off the actual share submitted tables and the block totals were taken from a different table (old table), but are now taken from the same table as share calculations.  Basically, it was purely a display bug and did not affect any balances or important calculations.

[cyberlync]

Thanks for the in-depth update.

[Inaba]

My Workers page should now accurately reflect the amount of PPS shares you submitted vs the DGM shares.  If your miner is set to PPS, it will indicate PPS shares, if it's set to DGM, it will indicate DGM shares. 

The exception is the "Reset" column, which will increment regardless of worker type.

[dave3]

Glad to hear it's all sorted out.

[Inaba]

I have made a slight change to the Paypal payout method.

Because of the high fees associated with Paypal payouts, I have instituted a $1 minimum payout.  Now, this does not mean YOUR payout needs to be at least $1 USD, it just means ALL payouts for that run need to add up to at least $1.  So those of you still doing .02 payouts can still do them, you'll just have to wait until enough have accumulated and/or you can piggyback on a larger payout.  Looking at historical records, this usually won't take more than an hour under all but the most unusual conditions. 

I apologize if this inconveniences anyone, but with the smaller payouts, I am taking a 10% fee loss (so I'm losing 6% for every payment) which is not sustainable.

For most people, this change will not affect you.  For the few that it does, the only change is that your payments may not be quite as "instant" as they were before.