Topic: [1423GH] ABCPool PPS - Proxy Pool For High & Steady Mining Rewards - page 12. (Read 151781 times)

Missed your post initially; to answer your question: Our systems are behind Amazon's load balancers, which cannot be pinged. To gauge response time you may time a fetch of http://www.abcpool.co/ping.php; it should be comparable to ping response time.

EDIT: This made me think.. why wouldn't the load balancers be pingable? So I poked around until I poked a little hole; and now pool.abcpool.co can be pinged

By the way, for those concerned about ping times: each 100ms of ping-time translates to only 0.017% invalid shares. In the grand scheme of things quite insignificant.

Hi guys,

We've hit another checkpoint on our way up the GH/s scale. That means registration has closed again while we analyze load patterns and prepare our systems for further scaling.

Registration will most likely open up again after the weekend. If you'd like a heads up, send chlorine or me a PM and you'll be the first to know when signing up is possible again.

MC

Just as individual miners goes to a pool to limit their risk, ABCPool also employs other pools to limit risk. That way we can offer you our risk free PPS service for such a low fee.

If a block is found at any of the pools we direct your hashes to, we receive a small payout. Many small payouts even out to a more predictable payout pattern than the several big payouts we would have when purely running our own bitcoind for mining. We use these payouts to pay your fixed PPS rewards.

A word about the term 'proxy'. Technically we're not a proxy, as we don't act on your behalf; look it up in the dictionary. Since it's now common vocabulary/jargon in the mining business, for now we'll stick with being described as a proxy. The first mining proxies were actually proxies in the dictionary-sense of the word, passing through both work and earnings directly, some running on your own computer, and some on a server. That also means that risk was passed on 1:1. When pools like ours emerged people also started calling them proxies, though we in fact establish a seperate and very different contract with our miners for a fixed PPS fee, thus transforming the risk of mining at DGM, Prop, Score, etc. pools to the risk free reward model of PPS.

what does that mean? utilizes other pools?

Please remember that ABC IS A PROXY. It is not a pool.

do you prohibit your address to be pinged? it doesn't respond (pool.abcpool.co)

Since the beginning of july we've been offline for about 75 minutes, so that's >99.8% uptime.

Good to hear that =) Maybe uptime % for the last month? I'll setup backup pools, but it'd be good to know what to expect from ABCPool

We'll be online all day for your hashing pleasure. And also the days, weeks and months after that into the foreseeable future

Anything specific we can help you with?

Is ABCPool online? I've tried to get to Mt.Red's admin on irc, but he's not available  I'm trying to find the best PPS pool atm.

Well if you want to add hopping proxys to this then Project X pays out about 110-115%+ usually.

Actually, projectX is paying slightly more currently 

Mtred is the highest at 100% PPS conventionally but other than that Bonuspool is the highest PPS.

This is untrue, isn't MtRed the highest paying PPS pool?

Thanks for your report spccioli. We're well aware of the issue. Keeping everyone continuously provided with work is our main development priority right now. You're completely correct in that it's not an easy task; First there's the load spike of all longpollers that need to be triggered, and immediately after that all miners will start refilling their internal queue by asking for even more work. Due to our nature as a pool of pools, we're generally among the first to hear about a new block. But that also means that we cannot reasonably keep dealing out saved-up work we know will only produce orphaned blocks; it would be a shameful waste of computing resources. There's still a couple of tricks in our bag that will improve response times after a block find though, and we're implementing those now.

MC

MintCondition,

first of all, congratulations for your first anniversary.

Then I have to say that lately I'm seeing more and more of these


As you can see 20 seconds after the longpoll my miner was still waiting for an answer.

I've seen it waiting even longer in several occasions.

This is a 6 GH/s miner.

I do understand that giving work to a couple thousand workers after a long poll is not an easy task so I'm just reporting this to you to let you know about this issue.

spiccioli

That's a helpful table right there I was keeping a similar table myself, coming to the same conclusions: the difference has now stopped growing.

First: The issue is solved. Rest assured, balances have always displayed the right amount of earnings. The inaccurate share count built up until now remains though, because the over-counted shares remain in our historical records. It would be too time-consuming to correct these. From now on the reported number of shares will grow in the same pace as balances again.

The issue is something that has been affecting the share count of all miners for a while now as it turns out. Thanks to your attentiveness (and let's not forget, a long code review sesion by Chlorine and me!) share accrual is now finally accurate again. It was most likely over-counting between 0.5-2.0%, judging from a DB analysis.

As mentioned before, balance accrual is done directly from the submitted shares. Stats calculation on the other hand, is a separate multi-stage process where the shares get tossed around and massaged into various useful bits of information. These help us manage the pool, and help you manage your miners.

[i had typed up a detailed report here, but it has some technical details that may be helpful to attackers, so I've yanked it. The gist is: one of the stats-stages had a subtle bug which became an issue once the pool grew.]

So, thanks again Mykel, now I hope you may finally start to enjoy the pool for a bit!

MC

First I want to congratulate you with your one year anniversary!

Second I appreciate it very much you are looking into the details of the issue.

I have also done some calculations I see that the differences become smaller as the total amount of submitted shares grows.
Please let me show you what I mean:



Hope this helps to find out was has been gone wrong if wrong at all.

Thank you & wish you a long and happy continuation of ABCPool!

Dear miners,

Today is an important day for your favorite little pool.. It’s exactly one year since ABCPool was first introduced to the world!

I remember our first users; it was pretty exciting. We’d say to each other: ‘Wow, this guy has 3GH/s, all by himself!’; and ‘hey, there’s another user, now we’ve already got 3 people hashing  at the same time!’. It seemed crazy: We only had a small mining rig ourselves, and there they were, all these people coming in, collectively bringing their gigahashes to the table..

That was then. Now, hundreds of people are connecting to ABCPool every day, and together we represent a significant piece of the hashrate-pie. ABCPool has grown tremendously over the past year, but the premise is the same as a year ago: steady earnings, day in day out.

To keep up with you guys, there have been countless improvements to the site, as many performance optimizations to the backend code, and we’ve scaled up our systems several times. Never a dull moment!

We’d like to use this opportunity to thank *you*, our loyal members, for your continued allegiance and trust in our little pool. Without you, ABCPool would be a hollow shell. And it wasn’t all fun and games: You’ve  stuck by us through some pretty rough times. We/you were stolen from three times and we’ve even had a botnet bring us down for a few days. But we struggled and the pool came out alright in the end!

By the way, we’ve got some pretty exciting stuff in the development pipeline right now. Stick around and when the time is right we’ll show you!

Thanks & Happy hashing,
Your pool ops as always,

MC & Chlorine

PS: Right now we’re working on MykelSilver’s problem; a  thorough examination of statistics scripts is underway. While account balance is calculated directly from incoming shares, share-count numbers are tossed around several times before appearing in your stats. We’re writing alternative (redundant) means of calculation for everything now, which will most likely flush out the problem.

I'm looking into it.