[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[WynX]

A long series of lucky rounds is needed to fulfil all shelved shares.

I don't think this will ever happen (call me skeptic), I've got .5 btc shelved (in CPPSRB) which have not been moving for months..

[1714005510]

1714005510

[1714005510]

1714005510

[matt4054]

To make it more clear:

Expected behavior: if the pool is unlucky, as my shelved shares are deeper and deeper in the queue (i.e. in the past), during the lucky phase at the start of each round, I will see 'estimated' graph at the start of each round with a lower threshold above the paid+unpaid graph, and decaying faster and faster, until I fall too deep in the queue and I reach the moment when it becomes flat.

Observed behavior: until June 26 I have seen expected behavior as described above, but it was far from becoming "flat" at that time (edit: unfortunately now we can hardly see it on the graph, it's too much in the past). Since then, the "estimated" graph is flat. It was all of a sudden, and it coincides with a short period (tens of seconds) when I submitted many shares, after being idle for long, and the staying idle for long. The hashrate graphs are correct (I currently no longer mine with that address, the spikes are just testing), but on the rewards graph, I can't understand the "break" of June 26.

Edit: another thing, the shelved shares date back from some (2-3) weeks ago, not months.

[HellDiverUK]

You may have seen yourself in the payout queue during the beginning of a round when the system could potentially have had enough to pay some of your shelved shares and bump you into the payout queue.  Most likely that didnt actually happen and the round was slightly longer than it needed to be to get to your shelved shares.  Normal behavior.  You'll likely have to continue mining if you want a faster payout, or your payout will timeout where it is at generally within a week if none of your shelved shares are paid.

Thanks, I sort of figured that after I posted, thanks to WynX.   Eagerly awaiting my payout. 

It will come , but Wizkid is right, next to my explanation, also the holding of shelved shares (by stopping hashing in a particular round) can contribute to removal from the payout queue. All is normal behaviour indeed. Keep hashing like you're doing now, it should be done in a few days .

Well I hit the payout threshold this morning, and saw my address at about 72nd in the payout queue.  I checked again a few minutes ago and my address has gone from the queue.  I've not received anything.  NOW I'm confused. 

[HellDiverUK]

And now I'm back in the queue again. 

[purelithium]

Having connectivity problems on both stratum and GBT.

[BitMinerN8]

Having connectivity problems on both stratum and GBT.

#eligius
[14:44] <handle> Luke-Jr: reboot

I'm sure it will be back soon.

[pikeadz]

back up for me.  how long was it down?

[toolbag]

Something's still not right. I'm getting a whole bunch of these:

Code:

Stratum connection to pool 0 interrupted
Pool 0 stratum+tcp://stratum.mining.eligius.st:3334 not responding!

[freshzive]

Something's still not right. I'm getting a whole bunch of these:

Code:

Stratum connection to pool 0 interrupted
Pool 0 stratum+tcp://stratum.mining.eligius.st:3334 not responding!

yeah cgminer has been leaking shares even with --failover-only. stats are reporting that I'm running about ~10% slower than I was for the previous 24 hours.

[spooderman]

Having some nice luck lately!

[toolbag]

Can someone explain what "leaking shares" means? I've been mining for a few months now but there's still quite a bit of the nitty-gritty details I don't fully understand.

[BitMinerN8]

Can someone explain what "leaking shares" means? I've been mining for a few months now but there's still quite a bit of the nitty-gritty details I don't fully understand.

It is my understanding that leaking of shares might happen when something is going on with the pool which causes your miners to switch over to your backup pool. This flip flop between pools causes a loss in shares as during the switch over a percentage are lost. In this case, via IRC, I read that Eligius was under a DDoS and WizKid057 was doing a fine job combating it. Needless to say though, you would be mining fine for a while, it would hiccup, your miner would switch to a backup, then after a minute or so switch back. My various rigs have stopped doing that since late last night, so I am assuming things were handled, it's been smooth sailing for many hours. (And we've had a nice little slice of luck!) 

[purelithium]

What am I doing wrong? the 3 are connecting by stratum when one should be GBT, one stratum and the other GW.

[iongchun]

What am I doing wrong? the 3 are connecting by stratum when one should be GBT, one stratum and the other GW.

The GBT/GW server "suggests" your miner to switch to Stratum server, and your miner accepts it.
You can use --fix-protocol for cgminer or --no-stratum for bfgminer to turn off this feature.

[purelithium]

Weird, I would have thought LukeJR's pool would use his protocol(especially when using his miner software)...

[The00Dustin]

Weird, I would have thought LukeJR's pool would use his protocol(especially when using his miner software)...

I know you weren't born yesterday, because I've seen you around.  That having been said (since I don't think I've seen you trolling):
1) LukeJr doesn't run this pool anymore, Wizkid does
2)

I'm assuming the folks who are having minor connectivity issues are still using getwork or GBT.  I would suggest a switch to stratum at this point, honestly, as it is less resource intense.  The getwork/GBT load on the server is absolutely insane, which is why I'm splitting the hosts up so that they can be partitioned and hosted separately soon.

[purelithium]

Fair enough. I've been out of contact with bitcoin for a few months, so I wasn't keeping up on all that. I'll just take out those connections as my backups and I'll get a third backup pool for just in case.

[wizkid057]

To make it more clear:

Expected behavior: if the pool is unlucky, as my shelved shares are deeper and deeper in the queue (i.e. in the past), during the lucky phase at the start of each round, I will see 'estimated' graph at the start of each round with a lower threshold above the paid+unpaid graph, and decaying faster and faster, until I fall too deep in the queue and I reach the moment when it becomes flat.

Observed behavior: until June 26 I have seen expected behavior as described above, but it was far from becoming "flat" at that time (edit: unfortunately now we can hardly see it on the graph, it's too much in the past). Since then, the "estimated" graph is flat. It was all of a sudden, and it coincides with a short period (tens of seconds) when I submitted many shares, after being idle for long, and the staying idle for long. The hashrate graphs are correct (I currently no longer mine with that address, the spikes are just testing), but on the rewards graph, I can't understand the "break" of June 26.

Edit: another thing, the shelved shares date back from some (2-3) weeks ago, not months.

Since about 2 days ago there is something weird with my stats/payouts, they seem to be "stuck" during rounds, and even during the lucky phase of each round, my shelved shares stay on the shelf.

It seems other contibutors' stats are OK. Could you please check this address? Thanks!

Bump, problem still there... thanks

This is not an actual problem.  You are no longer mining here, and your older shelved shares are pushed behind the new shares from active miners during our past few unlucky rounds.  Since you are not mining, you no longer have any new shares in the top portion of the share log. So, this will make it take longer for the pool to dig down to the shares you do have in the share log, which are under the shares that are from active miners from the recent rounds which ere not yet fully paid.

Summary:  this is normal behavior.

I think I understand CPPSRB quite well and, sorry, but I must insist:

Until June 26, I could clearly see my shelved shares getting included early during the lucky phase of rounds.

Since June 26, after a short "share strobe" (many shares for less than a minute), I have never seen any shelved share, even early after several rounds with much more than 100% luck / <50% CDF, taken from my shelved shares to payout. Not a single one. It is now the last day where you can see the "not flat" part on my stats graph.

To make my point stronger, I will make a 0.2 BTC donation (0.1 as a donation to the pool and 0.1 to the one that explains it to me, probably Wizkid) if you can look at it again, and explain to me why such a difference between before June 26 and after June 26, and again come to the conclusion that this is perfectly normal.

Thanks.

EDIT: 1st suspect to my eyes are these "strobes", you can see the 1st strobe coincides with the moment when I wouldn't get any more shares "unshelved" from that point.

First, let me point out that no donations are needed for this.  I'd much rather you understand the system regardless.

I'm not sure what you mean by "strobes", but I will attempt to explain your personal situation in as much detail as possible.

Lets first take a look at a historical graph of your mining hashrate and balance changes:



And now lets take a closer look at the time after you stopped mining with the pool:



Before I go any further, let me point out that based on these graphs, approximately 0.2 BTC in shelved shares were in fact rewarded to you in the period between the time you stopped mining with us and now.

I believe you somewhat understand the spikes in the estimated balance are the shelved shares that could be paid at the start of a round (lucky) and tapering off as a) no new shares from active mining are added, and b) less of your shelved shares are in the top 25 BTC of the share log as they are pushed further down by active miners' shares.  This is exactly what is happening here in your graph.

So, to set the stage, your most recent shelved share was mined on 2013-06-21.  Then, after that, 0.2 BTC worth were paid/rewarded, making it so your most recent shelved share is even older than that since your newest ones were paid first.  I'll spare you the math in figuring it out (can be estimate with the graphs alone), but as of today your newest shelved share is from approximately 2013-06-17.

So, in order for your shelved shares to be in the top 25 BTC of the share log, and thus have an estimated payout (spike in the estimate balance graph) possible that means that every share from right this moment all the way back to 2013-06-17 would need to be either already paid or total less than 25 BTC.  Consider that is nearly three weeks of time, and there have been many unlucky rounds in that time frame, neither is likely.

It looks like, according to your graph, your shelved shares stopped being in the top of the share log around 2013-06-25.  Specifically, the last block that caused your estimated balance graph to change was 243,363 (compare the times). Lets take a look at the block history from that time frame forward:



Here is the meat of this whole exercise: Notice that block 243,363 was unlucky, 44,469,230 shares at difficulty 19,339,258.  That means this block alone put 25,129,972 newer shares than yours on top of the share log as new shelved.  When block 243,429 was found, the top of the share log (25 BTC, or approximately 19,339,258 shares) was taken as estimated payouts for this new round.  But wait, 25,129,972 in shelved shares were just added on top of your shelved.  25,129,972 > 19,339,258, thus your shelved shares are no longer in the top 25 BTC of the share log.  Looking further up the block list, block 243,429 was also unlucky, adding approximately 23,342,644 more shares on top of your shelved.  So, just the next two blocks alone have buried your shelved shares under over 48 million active miner shares.  Take into consideration that there was a decent run of unlucky blocks to follow, and your shelved shares are so far under currently active miners' shares that there is no way they would be near the top of the share log any time soon.

So, the system is working perfectly, you just stopped mining at a particularly unlucky time, not that you had any way of knowing that.

CPPSRB variance averages out, generally over approximately 60+ days, to level off in the upper 90s% PPS, even 100% PPS at times. (See variance graph on the stats page)  You had only mined with Eligius for about 4 weeks, which, taking into account the bad luck rounds in that time and to follow, is definitely not enough time for variance to average out nicely to a high % PPS.  Even so, according to your stats page you were paid over 90% PPS on average for your work.  This definitely would have been higher had you continued to mine with us, or had the pool been more lucky.

In any case, the system is working perfectly.  Under CPPSRB active miners always have an advantage, since they will always have shares in the top 25 BTC of the share log, and thus are always earning.  When you stop mining you are purely at the mercy of the luck that follows, which in your case was not the best.

I hope this helps you understand the setup better and the details of your particular situation.

-wk

[Luke-Jr]

Weird, I would have thought LukeJR's pool would use his protocol(especially when using his miner software)...

There are two reasons stratum has become the preferred protocol:

• GBT uses a fixed amount of bandwidth regardless of hashrate, and was designed for ASICs, not CPUs. For ASICs, fixed bandwidth is a pretty good thing: much less compared to getwork, but for CPUs, it's absurdly high! Unfortunately, the stupid botnets blindly adopted GBT and were creating major bandwidth issues for Eligius.
• GBT is not yet fully implemented. The server is currently expected to send every client a full set of transactions to put in blocks. This adds to the bandwidth needed for it. A full GBT implementation gets this transaction data from your local bitcoind, not the pool. I am working on getting full GBT support into Eloipool (or a rewrite) and BFGMiner, but it takes time to get everything just right.

I expect that when GBT is finished, it can once again become the preferred protocol.

[wizkid057]

Weird, I would have thought LukeJR's pool would use his protocol(especially when using his miner software)...

There are two reasons stratum has become the preferred protocol:

• GBT uses a fixed amount of bandwidth regardless of hashrate, and was designed for ASICs, not CPUs. For ASICs, fixed bandwidth is a pretty good thing: much less compared to getwork, but for CPUs, it's absurdly high! Unfortunately, the stupid botnets blindly adopted GBT and were creating major bandwidth issues for Eligius.
• GBT is not yet fully implemented. The server is currently expected to send every client a full set of transactions to put in blocks. This adds to the bandwidth needed for it. A full GBT implementation gets this transaction data from your local bitcoind, not the pool. I am working on getting full GBT support into Eloipool (or a rewrite) and BFGMiner, but it takes time to get everything just right.

I expect that when GBT is finished, it can once again become the preferred protocol.

To put things in perspective, Eligius used about 30 TB of bandwidth in the first 30 days of using the new server with GBT not redirected to stratum.  Talking about around 100 megabit commit, which is, in general, prohibitively expensive. We had peaks to over 0.5 gigabit outbound during longpoll at peak times, which is ridiculous for something that should be pretty simple.

Since the recent changes we're down to under 1/3rd of previous bandwidth usage.  Still quite a few people using GBT by disabling stratum redirection in their miners, and more power to them.  I think GBT is definitely going to end up as the preferred protocol, but, in it's current bandwidth hungry state, it is pretty wasteful when every miner, big and small, uses it.

*cheers for GBT 2.0*

-wk