Topic: [1423GH] ABCPool PPS - Proxy Pool For High & Steady Mining Rewards - page 59. (Read 151781 times)
August 17, 2011, 07:49:53 AM
The rate of invalids seems very high. I have ~60,000 shres and ~2,000 invalids. Is this normal? What makes a share invalid? I have not had this problem with other pools.
August 17, 2011, 07:15:42 AM
Damn i noticed same thing but i thought it was my own sucky internet connection 
Heh i even reseted by modem and setup'd it
Damn from now on im reading firts
forum before i act on my own 5hrs of lost works is a lot for small miner like me.
Heh i even reseted by modem and setup'd it
Damn from now on im reading firtsforum before i act on my own
5hrs of lost works is a lot for small miner like me.
August 17, 2011, 07:02:56 AM
Our backend got stuck around 07:00 UTC, and has just been forcibly restarted. As a consequence, ABCPool has been out of operation for approx. 5 hours. We are doing a post-mortem on the incident now.
ABCPool is currently operational again. Please restart your miners if they have become disconnected.
ABCPool is currently operational again. Please restart your miners if they have become disconnected.
August 17, 2011, 02:31:58 AM
>Current Hashrate:0 GH/s
>Current Workers:0
And my GUIMiner gets stuck on "Connecting". What's going on?
>Current Workers:0
And my GUIMiner gets stuck on "Connecting". What's going on?
August 16, 2011, 11:50:39 PM
Your site seems to log me out very frequently. Is it possible to increase the login timeout?
I hate it when sites do that.. And you're absolutely right: I've also noticed it myself a couple of times on ABCPool. I'll have a look at it tomorrow to see if I can extend the session expiration time. August 16, 2011, 07:47:38 PM
Your site seems to log me out very frequently. Is it possible to increase the login timeout?
August 16, 2011, 11:09:15 AM
I'd really like it if you could remove the fees on manual withdrawals.
The fees are intended as a deterrent from spamming the blockchain (and our ledger) with micro-transactions. As soon as the exchange rate gets sufficiently higher we will consider lowering the fee-boundary.Quote
Lots of pools allow the option to cash out when you have at least 0.01 BTC with no fees.
But do these pools also offer 0% PPS with paid stales? 
August 16, 2011, 10:52:00 AM
Speaking of withdraws, I initiated a one three hours ago and it hasn't showed up in Mt. Gox.
I'm sorry to hear that. I've found your transaction. It was included in a block within 10 minutes of initiating it. I have just PM'd you your payout history, I hope it clears things up!
Quote
Is there a way to look at the payout history?
Payout history is one of the features we are working on this week. We've heard your request 
August 16, 2011, 10:08:43 AM
Speaking of withdraws, I initiated a one three hours ago and it hasn't showed up in Mt. Gox. Is there a way to look at the payout history?
August 16, 2011, 03:57:22 AM
I'd really like it if you could remove the fees on manual withdrawals. Lots of pools allow the option to cash out when you have at least 0.01 BTC with no fees.
August 15, 2011, 04:50:42 PM
Would you guys be willing to show the buffer amount you have for the pool within your stats page? Is there a reason for not having this transparency?
Tbh it doesn't matter in pure PPS as long as it keeps paying..Your posts have me thinking about adding some kind of solvency indicator and a failsafe that shuts down the pool in case wallet balance threatens to creep below the member balances. That way miners can be confident that they can withdraw their earnings; even if the entire pool management should die in an air disaster while on corporate retreat.
Regardless of any promises made by us or any other pool, we advise our miners to withdraw their earnings regularly. For reasons mentioned in another thread, https://bitcointalksearch.org/topic/--34282, ABCPool does not intend to be a bank. We don't want to be holding on to large amounts of BTC for our members.
Quote from: gigasvps
Also, I don't see a found blocks page. Do you not show when you find blocks?
I guess these things are not absolutely necessary to run a pps pool...
We know that our stats are currently pretty basic. We plan to introduce extra stats on the individual level, so users have more insight into their performance. We expect to work on that after this week.I guess these things are not absolutely necessary to run a pps pool...
August 15, 2011, 04:18:04 PM
Would you guys be willing to show the buffer amount you have for the pool within your stats page? Is there a reason for not having this transparency?
Also, I don't see a found blocks page. Do you not show when you find blocks?
I guess these things are not absolutely necessary to run a pps pool... but the more transparency the better.
Also, I don't see a found blocks page. Do you not show when you find blocks?
I guess these things are not absolutely necessary to run a pps pool... but the more transparency the better.
Tbh it doesn't matter in pure PPS as long as it keeps paying.. Found blocks are irrelevant to the miner
There is no info or blocks to withhold, miners just agree to submit shares and get paid for them.. In this case even stales
He can keep whatever surplus he gets & there is nothing suspicious about it.
Unlike prop or *mpps pools, the found BTC are not the property of miners, but rather profits of the operator who can decide what he wants to do with them
August 15, 2011, 03:23:10 PM
Would you guys be willing to show the buffer amount you have for the pool within your stats page? Is there a reason for not having this transparency?
Also, I don't see a found blocks page. Do you not show when you find blocks?
I guess these things are not absolutely necessary to run a pps pool... but the more transparency the better.
Also, I don't see a found blocks page. Do you not show when you find blocks?
I guess these things are not absolutely necessary to run a pps pool... but the more transparency the better.
August 15, 2011, 12:04:35 PM
Quote
Lifetime Valid: 13290 shares
Lifetime Stale: 28 shares
Lifetime Invalid: 28 shares
Lifetime Stale: 28 shares
Lifetime Invalid: 28 shares
Are these acceptable? For few days?
Im using 2 cards as presented in my sig?
August 15, 2011, 11:56:59 AM
Quote
Lifetime Valid: 13290 shares
Lifetime Stale: 28 shares
Lifetime Invalid: 28 shares
Lifetime Stale: 28 shares
Lifetime Invalid: 28 shares
Are these acceptable? For few days?
Im using 2 cards as presented in my sig?
Im happy for results i get as its hazzle free and easily see what i get
August 15, 2011, 11:12:35 AM
To all other Bithopper users: I recommend to switch clients or to use another pool while this issue persists to avoid excess strain on our systems.
i told them in their forum.
i think you could be a very good backup pool
looking forward to get things sorted
August 15, 2011, 11:02:28 AM
tomorrow i'll look into bitHopper proxy code i'll see if i find any hint (i won't switch my client, but i really don't want to ddos you
You are free to try for now. NB: I have changed hashrate computation code to include only valid shares and stales. This should still give a good approximation while also preventing inflated numbers due to invalid shares.
To all other Bithopper users: I recommend to switch clients or to use another pool while this issue persists to avoid excess strain on our systems.
August 15, 2011, 10:37:26 AM
i disabled you for now (did my login at work and forgot to take account details to my home...)
tomorrow i'll look into bitHopper proxy code i'll see if i find any hint (i won't switch my client, but i really don't want to ddos you.
as far as i know bitHopper it builds up the following connections to you:
LP Call: (no data transmitted, connection will stay alive)
getwork: {'method':'getwork', 'params':data, 'id':i} (i is a number just counting up, data is NULL or a submitted share) (approx 0.5/sec - LESS than with my three single miners connected)
delag call:same as getwork (approx every ten seconds if your pool is marked as lagged)
bithopper does mark your server as lagged if: the getwork returns NULL or the call did not get to your server properly.
with all other pools it works flawlessly (if you allow me ddossing you for a few minutes) - tomorrow evening i'll look a little deeper. maybe i can tell you what makes you think of an invalid.
btw: eligius does count stale and invalids also. with them i never get any invalids and very few rejects. so i still think its on your side.
tomorrow i'll look into bitHopper proxy code i'll see if i find any hint (i won't switch my client, but i really don't want to ddos you
.as far as i know bitHopper it builds up the following connections to you:
LP Call: (no data transmitted, connection will stay alive)
getwork: {'method':'getwork', 'params':data, 'id':i} (i is a number just counting up, data is NULL or a submitted share) (approx 0.5/sec - LESS than with my three single miners connected)
delag call:same as getwork (approx every ten seconds if your pool is marked as lagged)
bithopper does mark your server as lagged if: the getwork returns NULL or the call did not get to your server properly.
with all other pools it works flawlessly (if you allow me ddossing you for a few minutes) - tomorrow evening i'll look a little deeper. maybe i can tell you what makes you think of an invalid.
btw: eligius does count stale and invalids also. with them i never get any invalids and very few rejects. so i still think its on your side.
August 15, 2011, 10:28:39 AM
Welcome to ABCPool flower1024!
Your invalid rate is indeed abnormally high. Only you and one other (<100Mh/s) user are currently experiencing through-the-roof invalid rates, so I would suspect the problem is with Bithopper. I have traced your submissions through our accounting pipeline, and everything checks out: In addition to the reported valid and stale shares you submit lots of invalid shares.
Note that you are effectively DOSing our servers
. But at such a low rate, we'll let it slide for now 
I do suggest you use a different client.
Hashrate reported by ABCPool is currently based on all shares submitted, even the invalid ones. With this we intended to approximate the rate reported by mining clients. For clients like Phoenix the current approach approximates client-reported hashrate best, because those clients have actually done the work for invalid shares they submit.
Your invalid rate is indeed abnormally high. Only you and one other (<100Mh/s) user are currently experiencing through-the-roof invalid rates, so I would suspect the problem is with Bithopper. I have traced your submissions through our accounting pipeline, and everything checks out: In addition to the reported valid and stale shares you submit lots of invalid shares.
Note that you are effectively DOSing our servers
. But at such a low rate, we'll let it slide for now I do suggest you use a different client.Hashrate reported by ABCPool is currently based on all shares submitted, even the invalid ones. With this we intended to approximate the rate reported by mining clients. For clients like Phoenix the current approach approximates client-reported hashrate best, because those clients have actually done the work for invalid shares they submit.
The other user is probably me. I'm showing 3276 lifetime invalid shares, but I've only submitted 499 shares so far this morning after signing up. I can't use another client so I'm disabling abcpool for now. I would like to figure this out though.
August 15, 2011, 10:22:50 AM
Welcome to ABCPool flower1024!
Your invalid rate is indeed abnormally high. Only you and one other (<100Mh/s) user are currently experiencing through-the-roof invalid rates, so I would suspect the problem is with Bithopper. I have traced your submissions through our accounting pipeline, and everything checks out: In addition to the reported valid and stale shares you submit lots of invalid shares.
Note that you are effectively DOSing our servers. But at such a low rate, we'll let it slide for now I do suggest you use a different client.
Hashrate reported by ABCPool is currently based on all shares submitted, even the invalid ones. With this we intended to approximate the rate reported by mining clients. For clients like Phoenix the current approach approximates client-reported hashrate best, because those clients have actually done the work for invalid shares they submit.
Your invalid rate is indeed abnormally high. Only you and one other (<100Mh/s) user are currently experiencing through-the-roof invalid rates, so I would suspect the problem is with Bithopper. I have traced your submissions through our accounting pipeline, and everything checks out: In addition to the reported valid and stale shares you submit lots of invalid shares.
Note that you are effectively DOSing our servers
. But at such a low rate, we'll let it slide for now I do suggest you use a different client.Hashrate reported by ABCPool is currently based on all shares submitted, even the invalid ones. With this we intended to approximate the rate reported by mining clients. For clients like Phoenix the current approach approximates client-reported hashrate best, because those clients have actually done the work for invalid shares they submit.
Jump to: