Due to concerns of pool hopping, I have implemented part of MaxPPS early. Miners will no longer be paid more than the PPS-value of their shares in short blocks. This means that when the block is found early, Eligius acts as a PPS pool (except without the huge fees usually associated with PPS). This also means there is a large buffer of extra mining coins in each block. To conclude the poll, I have decided to compromise the minimum payout: it will be gradually reduced to 0.33 554432 BTC. Please note that long blocks are still on the old proportional payment schedule until the "big upgrade". I am aware that over the long run, this current payment schedule can result in insane benefit to the pool at the expense of the miners, but I hope to wrap up the "big upgrade" before it has any practical effects in this way, and at the time of the big upgrade, I plan to have the MaxPPS retroactively be applied to the present so anyone mining on the long blocks will have their work on short blocks reimbursed properly.
This rambling is probably very confusing, so please ask questions if you need clarification on anything.
Topic: [350 GH/s] "Eligius" (experimental) pool: almost feeless PPS, hoppers welcome - page 12. (Read 116997 times)
June 13, 2011, 01:46:19 PM
June 13, 2011, 12:56:05 PM
Maybe this is a stupid question, but where can i look up the total sum of shares i've processed for the current block?
On my personal stats i can see a 3h and 15min average, but where are the totals? And can i look up the stales and rejected blocks somewhere as well?
Besides that, keep up the good work!
Edit:
On a side note, i get tons of RPC errors today ("Problems communicating with bitcoin RPC", "upstream RPC error") when mining with your pool. I have BTCGuild running on low priority as a backup and this is running quite smoothly.
On my personal stats i can see a 3h and 15min average, but where are the totals? And can i look up the stales and rejected blocks somewhere as well?
Besides that, keep up the good work!
Edit:
On a side note, i get tons of RPC errors today ("Problems communicating with bitcoin RPC", "upstream RPC error") when mining with your pool. I have BTCGuild running on low priority as a backup and this is running quite smoothly.
June 13, 2011, 09:42:18 AM
Awesome work, Artefact2.
Thanks!
June 13, 2011, 08:59:20 AM
Superb work, Artefact, thanks! Is there any chance of an 'Expected block duration' figure? Obviously it's all probabilistic, but it'd be quite nice to see at a glance how long we would expect the next payout to take (and how far from the average those recent outliers are!).
June 13, 2011, 08:33:53 AM
Okay, I've added some new features to the stats.
I hope you enjoy then, and as always, if you want to donate, it's very much appreciated (1666R5kdy7qK2RDALPJQ6Wt1czdvn61CQR) !
Also, I'm not really bragging about it (and maybe I should), but these statistics are open-source (AGPLv3), you can review (and improve!) the source here : https://github.com/Artefact2/eligius-stats
I hope you enjoy then, and as always, if you want to donate, it's very much appreciated (1666R5kdy7qK2RDALPJQ6Wt1czdvn61CQR) !
Also, I'm not really bragging about it (and maybe I should), but these statistics are open-source (AGPLv3), you can review (and improve!) the source here : https://github.com/Artefact2/eligius-stats
June 13, 2011, 03:58:33 AM
Okay, that makes sense. I'm still sticking with Eligius, though. I like it. The fact that I can just go without any registration or e-mail or hackable account and that I get my coins immediately from generation once I have 1 BTC together.
Also I like the stats 2.0 page, everything I need to know about "my" pool right there.
Let's support the small pools! (Until they become big, then we have to switch to smaller pools again
)
Also I like the stats 2.0 page, everything I need to know about "my" pool right there.
Let's support the small pools! (Until they become big, then we have to switch to smaller pools again
) 
June 13, 2011, 03:46:39 AM
Yeah, especially the current round needs to be shortened. What's up with that? 17 hours and no block found?
Please tell me I shouldn't freak out and immediately drop out!!1! (which I won't do BTW...)
Is this normal because of the random nature of mining or are there suddenly a lot of professional solo miners with huge rigs that are gobbling up all the valid hashes? It seems lately all the blocks generated belong to solo miners, I don't see any pools anymore.
Please tell me I shouldn't freak out and immediately drop out!!1! (which I won't do BTW...)
Is this normal because of the random nature of mining or are there suddenly a lot of professional solo miners with huge rigs that are gobbling up all the valid hashes? It seems lately all the blocks generated belong to solo miners, I don't see any pools anymore.
It is partially to do with the random nature of mining. But the fact is that we are being outcompeted by larger pools. I think that pools still rule the roost sort of speak. Just look at Deepbit. Their rounds must last mere minutes!
June 13, 2011, 03:33:16 AM
Yeah, especially the current round needs to be shortened. What's up with that? 17 hours and no block found?
Please tell me I shouldn't freak out and immediately drop out!!1! (which I won't do BTW...)
Is this normal because of the random nature of mining or are there suddenly a lot of professional solo miners with huge rigs that are gobbling up all the valid hashes? It seems lately all the blocks generated belong to solo miners, I don't see any pools anymore.
Edit:OK, I just realized that Eligius is probably the only pool that transfers coins directly upon generation. The others seem to only give one address in generation and then transfer the coins to their participating nodes. BTCGuild reports having mined block 130458, for example, which I thought to be a solo block according to BlockExplorer.
I just hope that it's not gonna be a lot more 10+ hours rounds and that we will be rewarded with a couple of short rounds soon...
Please tell me I shouldn't freak out and immediately drop out!!1! (which I won't do BTW...)
Is this normal because of the random nature of mining or are there suddenly a lot of professional solo miners with huge rigs that are gobbling up all the valid hashes? It seems lately all the blocks generated belong to solo miners, I don't see any pools anymore.
Edit:OK, I just realized that Eligius is probably the only pool that transfers coins directly upon generation. The others seem to only give one address in generation and then transfer the coins to their participating nodes. BTCGuild reports having mined block 130458, for example, which I thought to be a solo block according to BlockExplorer.
I just hope that it's not gonna be a lot more 10+ hours rounds and that we will be rewarded with a couple of short rounds soon...
June 13, 2011, 03:18:32 AM
All requests are over JSON/HTTP so only TCP....
You can see the status of the eligius servers and uptime at
http://eligius.st/~artefact2/
There was a recent bump in St. Eligius US.
Ah ok, TCP it is.
Yep I know about that site link.
There was but then it went down to 117 Ghash.
I wish more people would join Eligius so we can shorten the rounds a bit.
June 13, 2011, 03:14:55 AM
All requests are over JSON/HTTP so only TCP....
You can see the status of the eligius servers and uptime at
http://eligius.st/~artefact2/
There was a recent bump in St. Eligius US.
June 13, 2011, 03:13:07 AM
Hey guys, anyone else but me get the occasional "warning: work queue empty, miner is idle"..when mining with phoenix ?
I'm using pheonix 1.48 aggression 12
Never had this issue with slush so far...
I'm using pheonix 1.48 aggression 12
Never had this issue with slush so far...
I'm surprised no one mentioned the -q flag… Try using -q 4 or -q 5, and see if it still happens as frequently. Basically it tells your miner to use a larger work queue.
Cool. Did the same and as supa mentioned the worker idle message disappeared. However I do still get disconnected from the server once in a while. I set a higher priority on my router to port 8337, but I'm wondering should I set it for both UDP and TCP or just TCP (I think it should be just TCP).
June 13, 2011, 03:05:40 AM
I'm surprised no one mentioned the -q flag… Try using -q 4 or -q 5, and see if it still happens as frequently. Basically it tells your miner to use a larger work queue.
This.
Bumped up the -q setting to 5 and that idle message disappeared.
Good call, Artefact2.
June 13, 2011, 02:33:47 AM
Hey guys, anyone else but me get the occasional "warning: work queue empty, miner is idle"..when mining with phoenix ?
I'm using pheonix 1.48 aggression 12
Never had this issue with slush so far...
I'm using pheonix 1.48 aggression 12
Never had this issue with slush so far...
I'm surprised no one mentioned the -q flag… Try using -q 4 or -q 5, and see if it still happens as frequently. Basically it tells your miner to use a larger work queue.
June 13, 2011, 02:02:27 AM
I see. So you'd suggest poclmb instead? or?
Another thing - and pardon me for not being up to date - , the two pools (EU and US) are not joined in any way, right?
Another thing - and pardon me for not being up to date - , the two pools (EU and US) are not joined in any way, right?
Right.
And Luke answered your question about "waiting for work" thing a few posts up.
I saw that, but that wasn't a definitive answer. As best as I can interpret it is says "it could be the miner it could not..." He did mention that the pool's work generation code is very inefficient, and I bet you anything that's the main reason. Once he improves the efficiency of the work generating code I will know for sure.
June 13, 2011, 01:57:53 AM
I see. So you'd suggest poclmb instead? or?
Another thing - and pardon me for not being up to date - , the two pools (EU and US) are not joined in any way, right?
Another thing - and pardon me for not being up to date - , the two pools (EU and US) are not joined in any way, right?
Right.
And Luke answered your question about "waiting for work" thing a few posts up.
June 13, 2011, 01:35:13 AM
I get the "idle" messages from phoenix too. I'm solo mining on other instance of phoenix with low agression just in case that this message appears to avoid my gpu to go up and down on temp.
Like I said (or I think I said it) previously, I don't have this problem with slush's pool. So I'm not sure 100% what is going on. I'll have to checkout the phoenix thread - maybe there is something that I missed.
June 13, 2011, 12:54:31 AM
I get the "idle" messages from phoenix too. I'm solo mining on other instance of phoenix with low agression just in case that this message appears to avoid my gpu to go up and down on temp.
June 13, 2011, 12:13:11 AM
The current code is very inefficient at generating work, so on long rounds it can take a number of seconds to return new work. I'm currently working on a new version to optimize it.
Cool. Thanks Luke for that explanation. So it is not the miner after all - that's a relief cause people have reported issues with phoenix in the past.Usually Phoenix problems are high invalid rates, though.
I see. So you'd suggest poclmb instead? or?
Another thing - and pardon me for not being up to date - , the two pools (EU and US) are not joined in any way, right?
June 12, 2011, 11:48:06 PM
The current code is very inefficient at generating work, so on long rounds it can take a number of seconds to return new work. I'm currently working on a new version to optimize it.
Cool. Thanks Luke for that explanation. So it is not the miner after all - that's a relief cause people have reported issues with phoenix in the past.Usually Phoenix problems are high invalid rates, though.
June 12, 2011, 11:35:34 PM
The current code is very inefficient at generating work, so on long rounds it can take a number of seconds to return new work. I'm currently working on a new version to optimize it.
Cool. Thanks Luke for that explanation. So it is not the miner after all - that's a relief cause people have reported issues with phoenix in the past.
Jump to: