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

[GenTarkin]

Im splitting shares between servers by using load-balance option in cgminer.
I have never used the cashout option

The block stats also show really high negative #'s where it never showed that before.
.. oh wait wtf that stat just disappeared in the block stat readout.
The one where it used to say (prop diff) or something...
I used to have stuff like +1.00034% , +.7203% , -.18382% -1.20583%....
but on the recent blocks it was progressively like this: -30%, -53%, -86% and -100%
now that stat is gone.
But recent block rewards *Seem to be coming up again. Since I switched back to mining on single server.
The current rewards are more inline w/ the recent hash increase. Kinda. I mean the pools been at 500gh/s before and I still could make .075btc / block.
Now its down to .06* per block.
At least it isnt as bad as the last 24hr, which was .04btc/block

[kano]

Your reward belongs to the shares you submitted, not the MHash!

Greetz
NetworkerZ

The Mhash should match up pretty close unless you have a low hash rate or the block was solved really quickly. Regardless I had 22867 shares in the block I was using for a example with 1215505 Total shares for the block which is .018812 % multiplied by 50 is .94 total reward. I don't see how it could be correct at .57 reward.

DGM does that for 2 reasons:
1) Your "capacitor" isn't fully charged
2) The pool got lucky

Yeah OK I missed another one
3) Pool hash rate goes up (a lot)

[Inaba]

Yeah, pool hashrate was at 700 GH/s for awhile, which probably accounts for your low earnings during those blocks.  As it settles down, it should increase.

I removed the prop differential for individual blocks, since it's kind of meaningless anyway.  Your overall prop differential is still at the bottom of the page for the past 50 blocks, and is a better metric as far as that goes, but it's still not completely accurate as it doesn't include "banked" + prop differential that you receive when you stop mining.

[cuz0882]

If the hash rate was 970gh my portion would have been even. My average is -23.22%. If I'm understanding it correctly I'm that far behind in earnings. So if I turned off my miners right now I would have lost 23% of my coins. Maybe I'm not understanding it correctly, but its not making sense to me.

[The00Dustin]

If the hash rate was 970gh my portion would have been even. My average is -23.22%. If I'm understanding it correctly I'm that far behind in earnings. So if I turned off my miners right now I would have lost 23% of my coins. Maybe I'm not understanding it correctly, but its not making sense to me.

If you turned off your miners now, you would earn for a few more blocks.  Look at the cashout amount.  That is your confirmed earnings + ((your unconfirmed earnings+an estimate of your remaining score value)-10%).  This should be closer to what you are expecting.  That is highly theoretical, though, I haven't done any math on this stuff.

[NetworkerZ]

Hey Inaba! Can you please add an option to delete not needed workers? I mean completly delete?!? THX!

Greetz
NetworkerZ

[Inaba]

No, there's not really any way to do that, as it would wreck past accounting.  It's actually a fundamental design issue (perhaps you could call it a flaw) suffered by most pools that use the worker paradigm.  I could possibly hide them permanently, but then you couldn't recreate a worker with that same name.

cuz - if you turned off your workers now, you'd still receive payments for the next ~7 blocks, which would recoup your 23%.  Does that answer your question or do you still have questions about it?  We had a fairly lengthy discussion of DGM several pages ago in this thread that might help clear things up, as well... but I will be happy to answer any additional questions.

[NetworkerZ]

I use BTCMon on my iPhone and I added my API Key to it. Now i can see all my workers, even the "deleted". It's a little bit confusing, that's the reason why I'm asking!

Greetz
NetworkerZ

[village.idiot]

Have you tried asking the app developer to fix the problem?

[NetworkerZ]

I think the tool just reads all the info it gets through the API Key. Will ask him to add a function not showing the deleted workers!

greetz
NetworkerZ

[Inaba]

Ah yeah that I can fix... and should be fixed in about 5 minutes.

[GenTarkin]

Back to the death blocks we go =/ inaba go kill some more people in BF3!

[kano]

Back to the death blocks we go =/ inaba go kill some more people in BF3!

One thing I have been wondering about that discussion ...
These are the same computers that are mining right? (or wrong?)
If they are then BF3 is reducing the pool hash rate ... ... ... ... ... ...

[Inaba]

Hah, yeah I guess they are... drops it by 1.6 GH/s.  I use a pair of 6990's to game.  It literally costs me money to game, jeez.

[Inaba]

Just got done killin' and see, we solved a block!

[cuz0882]

We could have shaved another minute off that!

[iNs4nePT]

No, there's not really any way to do that, as it would wreck past accounting.  It's actually a fundamental design issue (perhaps you could call it a flaw) suffered by most pools that use the worker paradigm.  I could possibly hide them permanently, but then you couldn't recreate a worker with that same name.

Just a thought, but maybe they could be marked as hidden and then renamed to something like hash(rand()) ?

[NetworkerZ]

Ah yeah that I can fix... and should be fixed in about 5 minutes.

THX! It worked!

Greetz
NetworkerZ

[village.idiot]

Here I go again 

ping us1.eclipsemc.com
PING us1.eclipsemc.com (208.110.68.114) 56(84) bytes of data.
^C
--- us1.eclipsemc.com ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11025ms

mickey@mickeyatwork ~ $ ping us2.eclipsemc.com
PING us2.eclipsemc.com (208.110.68.115) 56(84) bytes of data.
^C
--- us2.eclipsemc.com ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11014ms

mickey@mickeyatwork ~ $ ping us3.eclipsemc.com
PING us3.eclipsemc.com (208.110.68.116) 56(84) bytes of data.
^C
--- us3.eclipsemc.com ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11021ms

mickey@mickeyatwork ~ $ traceroute us2.eclipsemc.com
traceroute to us2.eclipsemc.com (208.110.68.115), 30 hops max, 60 byte packets
 1  * * *
 2  ge-2-10-ur01.east.tn.knox.comcast.net (68.85.38.93)  15.391 ms  16.938 ms  18.150 ms
 3  te-8-1-ar01.bluelight.tn.knox.comcast.net (68.86.136.30)  19.393 ms  20.639 ms  22.264 ms
 4  xe-2-1-0-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.136.18)  23.493 ms  24.756 ms  28.212 ms
 5  pos-3-7-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.205)  33.545 ms pos-3-8-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.95.197)  35.003 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125)  32.171 ms
 6  pos-0-4-0-0-pe01.56marietta.ga.ibone.comcast.net (68.86.87.138)  36.283 ms  25.703 ms  28.843 ms
 7  te4-2.ccr01.atl02.atlas.cogentco.com (154.54.10.233)  26.367 ms  28.001 ms  28.105 ms
 8  te0-0-0-1.mpd22.atl01.atlas.cogentco.com (154.54.3.145)  41.449 ms  41.504 ms  41.667 ms
 9  te0-3-0-6.mpd22.ord01.atlas.cogentco.com (154.54.29.90)  33.939 ms te0-1-0-6.mpd22.ord01.atlas.cogentco.com (154.54.29.82)  37.112 ms te0-3-0-6.mpd22.ord01.atlas.cogentco.com (154.54.29.90)  34.443 ms
10  te0-1-0-2.mpd22.mci01.atlas.cogentco.com (154.54.3.202)  57.520 ms te0-3-0-1.mpd22.mci01.atlas.cogentco.com (154.54.7.165)  57.805 ms te0-0-0-3.mpd22.mci01.atlas.cogentco.com (154.54.25.77)  59.070 ms
11  everest.demarc.cogentco.com (38.104.86.2)  54.451 ms  60.138 ms  57.155 ms
12  69.30.209.1 (69.30.209.1)  58.684 ms  50.549 ms  55.186 ms
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

[Inaba]

So it looks like the problem is here: 68.85.38.86

I'm not sure who owns that, probably comcast, but it appears that router has some weird routing loop going on when connecting to 208.110.68.0/24. 

traceroute to XXX.XXX.XXX.109 (XXX.XXX.XXX.109), 30 hops max, 60 byte packets
 1  69.30.224.129 (69.30.224.129)  88.550 ms  88.537 ms  88.527 ms
 2  69.30.209.125 (69.30.209.125)  88.439 ms  88.444 ms  88.439 ms
 3  te0-3-0-4.mpd22.mci01.atlas.cogentco.com (38.104.86.1)  88.444 ms  88.443 ms  88.435 ms
 4  te0-4-0-5.ccr22.dfw01.atlas.cogentco.com (154.54.46.214)  88.460 ms te0-2-0-5.ccr22.dfw01.atlas.cogentco.com (154.54.80.105)  88.439 ms te0-0-0-0.mpd21.mci01.atlas.cogentco.com (154.54.30.149)  88.365 ms
 5  te0-0-0-0.ccr21.dfw01.atlas.cogentco.com (154.54.46.165)  88.400 ms te0-1-0-6.ccr21.dfw01.atlas.cogentco.com (154.54.3.17)  88.393 ms te7-3.ccr02.dfw03.atlas.cogentco.com (154.54.6.62)  288.283 ms
 6  te8-1.mpd01.dfw03.atlas.cogentco.com (154.54.25.9)  288.304 ms  299.794 ms  299.780 ms
 7  be-10-304-pe01.1950stemmons.tx.ibone.comcast.net (173.167.56.165)  99.781 ms  99.781 ms be-10-204-pe01.1950stemmons.tx.ibone.comcast.net (75.149.230.149)  99.771 ms
 8  pos-2-4-0-0-cr01.dallas.tx.ibone.comcast.net (68.86.87.217)  99.754 ms  99.751 ms  99.721 ms
 9  pos-0-11-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.222)  99.766 ms  99.756 ms  99.745 ms
10  so-7-1-0-0-ar01.goodslettvll.tn.nash.comcast.net (68.86.90.190)  99.748 ms  99.747 ms  99.742 ms
11  ae-3-0-ar03.nashville.tn.nash.comcast.net (68.86.148.70)  99.946 ms te-9-4-ar01.bluelight.tn.knox.comcast.net (68.86.176.142)  99.952 ms ae-2-0-ar03.nashville.tn.nash.comcast.net (68.85.174.237)  99.849 ms
12  te-8-3-ur01.east.tn.knox.comcast.net (68.86.136.29)  99.865 ms  99.859 ms  99.842 ms
13  68.85.38.86 (68.85.38.86)  99.815 ms  99.805 ms  99.784 ms
14  * 68.85.38.86 (68.85.38.86)  99.748 ms *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *^C