Author

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

legendary
Activity: 1204
Merit: 1000
฿itcoin: Currency of Resistance!
I just had to take 9009 offline briefly (as well as 8337).  I put up a new server in addition to the old one.

So here are the options:

us.eclipsemc.com:8337
us.eclipsemc.com:9009
us2.eclipsemc.com:8337

I think the problem/bottleneck may be in bitcoind and not the getwork server.  That being the case, I am going to have to poke at the source code for bitcoind.  Still investigating this possibility at the moment.

Is anyone still having connection problems?

Can't connect to:

us.eclipsemc.com:8337
us.eclipsemc.com:9009

Will try us2.//
member
Activity: 114
Merit: 10
The EU server is down? DO I have to connect to the US now?

Greetz
NetworkerZ
legendary
Activity: 1260
Merit: 1000
I just had to take 9009 offline briefly (as well as 8337).  I put up a new server in addition to the old one.

So here are the options:

us.eclipsemc.com:8337
us.eclipsemc.com:9009
us2.eclipsemc.com:8337

I think the problem/bottleneck may be in bitcoind and not the getwork server.  That being the case, I am going to have to poke at the source code for bitcoind.  Still investigating this possibility at the moment.

Is anyone still having connection problems?
legendary
Activity: 1204
Merit: 1000
฿itcoin: Currency of Resistance!
All miners down... Port 8337... Will try 9009 for the first time...
full member
Activity: 226
Merit: 100
Hmm, I am just now having some connection issues, using port 9009 on the miners. As writing, eu.eclipsemc.com is down, but us.eclipsemc.com is up...
full member
Activity: 180
Merit: 100
I just switched to 9009.. let you know if it changes anything.
legendary
Activity: 1260
Merit: 1000
And it doesn't happen at other times?  If so, it's the getwork server getting backed up... I will have to consider how best to handle that.
full member
Activity: 150
Merit: 100
I saw that happen yesterday a couple times as well... I'm not sure what its causing it.  Try switching to port 9009 and see if continues?

I've been having the same connection issues, and it seems to happened right after we solve a block.  I noticed this 3 times lately, because my miners will switch to a backup pool immediately after solving a block.  Then they reconnect to EMC very shortly afterwards (1-3 minutes).

I don't know if that will help narrow it down or not.
legendary
Activity: 1260
Merit: 1000
I saw that happen yesterday a couple times as well... I'm not sure what its causing it.  Try switching to port 9009 and see if continues?
full member
Activity: 180
Merit: 100
Just FYI - EMC seems to be having connectivity problems.  I've had three instances of > 2 minutes without being able to connect..  My connection is working during those times.

Enigma


[19/01/2012 12:40:00] Result: 10e98463 accepted
[19/01/2012 12:40:10] Result: fbc7511f rejected
[19/01/2012 12:40:18] Disconnected from server
[19/01/2012 12:40:23] Result: 4bcd534a rejected
[19/01/2012 12:40:24] Warning: work queue empty, miner is idle
[19/01/2012 12:40:28] Result: 7a2500db rejected
[19/01/2012 12:40:33] Failed to connect, retrying...
[19/01/2012 12:40:44] Failed to connect, retrying...
[19/01/2012 12:40:59] Failed to connect, retrying...
[19/01/2012 12:41:14] Failed to connect, retrying...
[19/01/2012 12:41:29] Failed to connect, retrying...
[19/01/2012 12:41:44] Failed to connect, retrying...
[19/01/2012 12:41:54] Connected to server
[19/01/2012 12:42:02] Result: 7a25148d accepted
donator
Activity: 2058
Merit: 1054
Well Meni got to the answer before I did.  Yeah, any time we have a short round, your prop differential is going to go in a crazy direction, mostly due to luck.  I'm not sure there is really anything to be done about that (except remove the prop differential from individual blocks).
I should also mention that the main difference between PPLNS and DGM is that the variance is reduced by having the operator absorb some of it, which means he will gain money on short rounds and lose some on long rounds (which averages out to 0, before any pool fees). In EMC the absorption is very weak so you will likely not notice the effect, but in general this could contribute to a negative prop diff in short rounds (and to a positive diff in long rounds).

But again this can only explain about a 1% diff, the 193% you saw is due to good luck on your part in managing to find shares in that short time span.
legendary
Activity: 1260
Merit: 1000
Well Meni got to the answer before I did.  Yeah, any time we have a short round, your prop differential is going to go in a crazy direction, mostly due to luck.  I'm not sure there is really anything to be done about that (except remove the prop differential from individual blocks).

full member
Activity: 180
Merit: 100
I see what you mean - I was 'lucky' during that block.  8 shares is more than I 'should' have found.

Thanks for explaining.

Enigma
donator
Activity: 2058
Merit: 1054
I'm still trying to wrap my head around DG scoring...  I'm doing very well at EMC, so I'm definitely not complaining.. Just trying to understand.

That really short block, as a perfect example..
uzgen   162821
(379)    19:31:23
2012-01-18   00:01:41   2777   99.78%   44/120    8   0.04907340
(-193.52%)    0.00024660
0.27% avg

Total shares = 2777
My shares = 8
Proportional = (8/2777)*50 = 0.14404033 BTC
My DG Payout = 0.04907340 BTC

Why does DG yield such a poor payout in this instance?  1/3 what pure proportional would have paid..
I'd need more data (and time) to give a definitive answer, but it looks like you're seeing variance in the number of shares you found. Let's say you have about 0.1% of the pool's total hashrate, so in a period of 2777 shares you'd expect to find 3 shares. DGM reward is influenced by your past work so will be comparable to that average. But if you were lucky and got 8 shares (which is definitely within the realm of possibility, chance for a Poisson variable with mean 3 to be at least 8 is 1.2%), your proportional reward will be much higher.

Additionally, it seems like the %prop stat may be .. wrong.. or at least misleading..  -193% of anything would be a subzero number..
-65.93% would seem more appropriate.. 65.93% less than what pure proportional would have been..
(.14404033 - .04907340) / .14404033 = 65.93
Maybe it's misleading, but it looks like it simply gives a percentage with DGM payout as the base, that is .14404033 - 193.52% * 0.04907340 = 0.04907340.
full member
Activity: 180
Merit: 100
I'm still trying to wrap my head around DG scoring...  I'm doing very well at EMC, so I'm definitely not complaining.. Just trying to understand.

That really short block, as a perfect example..
uzgen   162821
(379)    19:31:23
2012-01-18   00:01:41   2777   99.78%   44/120    8   0.04907340
(-193.52%)    0.00024660
0.27% avg

Total shares = 2777
My shares = 8
Proportional = (8/2777)*50 = 0.14404033 BTC
My DG Payout = 0.04907340 BTC

Why does DG yield such a poor payout in this instance?  1/3 what pure proportional would have paid..

Additionally, it seems like the %prop stat may be .. wrong.. or at least misleading..  -193% of anything would be a subzero number..
-65.93% would seem more appropriate.. 65.93% less than what pure proportional would have been..
(.14404033 - .04907340) / .14404033 = 65.93

Enigma
hero member
Activity: 560
Merit: 500
Ad astra.
I've added additional stats to both text messages and emails.  Should go out next block solve (after 162815).

*EDIT* Had the numbers backwards.  Next block should have correct hashrate calculations.

That was our shortest block yet.  Only 2777 shares!

Glad to get a piece of it!
member
Activity: 94
Merit: 10
I added a variable to do as you describe:  On the end, after "userstats" tack on "&mh=y"

That will return your hashrate in MH only.

Thank you!
legendary
Activity: 1260
Merit: 1000
I've added additional stats to both text messages and emails.  Should go out next block solve (after 162815).

*EDIT* Had the numbers backwards.  Next block should have correct hashrate calculations.

That was our shortest block yet.  Only 2777 shares!
legendary
Activity: 1260
Merit: 1000
I added a variable to do as you describe:  On the end, after "userstats" tack on "&mh=y"

That will return your hashrate in MH only.
member
Activity: 94
Merit: 10
Is there any way you can change my userstats API information so the worker hashrates are only displayed in MH, and never in GH?

I'm trying to get my rainmeter skin to properly read all the data, and I'm pretty bad at coding so right now I can only get it working if they are all in MH.

Username is EpicBacon

Edit: I have it working now, but if my hashrate ever drops below 1GH/s on one of my workers then it will break.
Jump to: