Topic: [ANN][FeatherCoin][PPLNS][Stratum] FeatherPool.com Pool - page 6. (Read 9648 times)
Most of the old unconfirmed blocks have been paid out. There are a few stragglers that I will be processing payments for manually. The payments for the old blocks will have a TX Type of CreditFix in your tx log.
thank you, once older payouts are fixed, I am jumping back in.
I have also not been credited with anything, from those missing blocks, my username is Klok.
Can you do something about it? is the problem fixed? I have moved to another poll until you fix that.
Can you do something about it? is the problem fixed? I have moved to another poll until you fix that.
Problem is in the process of being fixed, should all be sorted out by tomorrow evening. All block rewards for blocks currently mined (and the last ~12ish hours) are being paid out properly and without issue.
I have also not been credited with anything, from those missing blocks, my username is Klok.
Can you do something about it? is the problem fixed? I have moved to another poll until you fix that.
Can you do something about it? is the problem fixed? I have moved to another poll until you fix that.
Unfortunately, I have not been credited with the FC for those 'unconfirming' blocks.
For instance, before the block history page was truncated from 500 to 50, I noted down that block 21959 was one of the blocks in questions. The credit for block 21959 still has not appeared in my transaction log (nor has there been a sudden increase in FC in my account).
For instance, before the block history page was truncated from 500 to 50, I noted down that block 21959 was one of the blocks in questions. The credit for block 21959 still has not appeared in my transaction log (nor has there been a sudden increase in FC in my account).
Addressing this now, thanks for the headsup.
Unfortunately, I have not been credited with the FC for those 'unconfirming' blocks.
For instance, before the block history page was truncated from 500 to 50, I noted down that block 21959 was one of the blocks in questions. The credit for block 21959 still has not appeared in my transaction log (nor has there been a sudden increase in FC in my account).
For instance, before the block history page was truncated from 500 to 50, I noted down that block 21959 was one of the blocks in questions. The credit for block 21959 still has not appeared in my transaction log (nor has there been a sudden increase in FC in my account).
All of the unpaid shares from those blocks that weren't confirming should now have been paid out. Sorry for any problems this has caused, and thanks to Steganos for helping me fix it.
Happy mining!
Happy mining!
Roughly how long does it take for the round reward to stablise?
I've been mining for about 2 hours and its still sitting at just under half of what it should be (and isn't increasing).
At 3GH, i would expect about 2.66 per round, but the estimate is 1.365.
I've been mining for about 2 hours and its still sitting at just under half of what it should be (and isn't increasing).
At 3GH, i would expect about 2.66 per round, but the estimate is 1.365.
It looks like blocks have been confirmed, but older shares have not been payed out. I think I see why.
In cronjobs/cronjob.php:
In cronjobs/cronjob.php:
Quote
///// Proportional Payout Method /////
...
$sql = mysql_query("SELECT blockNumber, count FROM ( ".
"SELECT blockNumber, count FROM `shares_uncounted` WHERE blockNumber <= " .$block. " ".
"UNION SELECT blockNumber, count FROM `shares_counted` WHERE blockNumber <= " .$block. " AND blockNumber > ".($block - 1000)." ".
")a ORDER BY blockNumber DESC");
...
"AND blockNumber > ".($block - 1000)"
This assumes that everything older than 1000 blocs has already payed, but that is probably not true. I don't remember which blocks we have started seeing problems with, but the range of blocks in the last 500 blocks found is greater than 1000. I think this number needs to be increased temporarily to get things back on track.
...
$sql = mysql_query("SELECT blockNumber, count FROM ( ".
"SELECT blockNumber, count FROM `shares_uncounted` WHERE blockNumber <= " .$block. " ".
"UNION SELECT blockNumber, count FROM `shares_counted` WHERE blockNumber <= " .$block. " AND blockNumber > ".($block - 1000)." ".
")a ORDER BY blockNumber DESC");
...
Quote
"AND blockNumber > ".($block - 1000)"
This assumes that everything older than 1000 blocs has already payed, but that is probably not true. I don't remember which blocks we have started seeing problems with, but the range of blocks in the last 500 blocks found is greater than 1000. I think this number needs to be increased temporarily to get things back on track.
Looks like you have a lot of blocks that you will have to manually process -- common problem with the server soft you're using.
Gah...can you shine some more light on this for me? You need to hook up with the admin at fc.dontmine.me -- he had a similar issue and was able to resolve it:
https://bitcointalksearch.org/topic/annfc-fc-simple-pool-dontmineme-lpstratum-179267
Just some more info for the simple pool:
PPLNS is over 1,000,000 shares so it takes a while to get the payout from one share.
Some blocks weren't paying, but I manually kicked them through the pipes so there should be a fresh (2k unspent in the pool + 1.6k from me = 3.6k) payout to the pool. Hopefully it's smooth sailing from here.
Right now the pushpool is running 56 MH/s and p2pool is at 22 MH/s.
PPLNS is over 1,000,000 shares so it takes a while to get the payout from one share.
Some blocks weren't paying, but I manually kicked them through the pipes so there should be a fresh (2k unspent in the pool + 1.6k from me = 3.6k) payout to the pool. Hopefully it's smooth sailing from here.
Right now the pushpool is running 56 MH/s and p2pool is at 22 MH/s.
I've got somewhere around 15000 unpaid shares at the moment on the pool 
How much did you increase it? There is now a very large sequence of blocks that have all been confirmed. That is a change from earlier. I also noticed from my transaction history that 4 blocks were credited to my account between 12:23:30 and 12:23:31. I think that having these 4 transactions confirmed during a period of 1 second is probably because you increased the value, but maybe it just wasn't increased enough to verify all of the earlier blocks.
The initial increase was not enough. I did increase it again and now all those old blocks are confirmed. Thanks for your help!
Now to get that Current Round Shares number sorted
As far as the FC client goes, that returns the most recent 240 transactions. I've increased this as well, but it doesn't seem to have had any effect.
How much did you increase it? There is now a very large sequence of blocks that have all been confirmed. That is a change from earlier. I also noticed from my transaction history that 4 blocks were credited to my account between 12:23:30 and 12:23:31. I think that having these 4 transactions confirmed during a period of 1 second is probably because you increased the value, but maybe it just wasn't increased enough to verify all of the earlier blocks.
featherpool has soon over 51% of power
People should go elsewhere!
People should go elsewhere!
How frequently are your cron jobs scheduled to run? The /cronjobs/README for mmcfe says:
Notes:
------
These scripts (from version 2.x.x forward) are intended to run every 60 secs. Best results will be achieved
if you configure your server to run them at the same interval. You risk missing new block information being
inserted into the database the longer you set the interval between these scripts running. Database load has
been significantly improved from version 2.x.x forward and it should now be perfectly safe to run these
scripts every 60 secs.
If the script is running less frequently than every 60 seconds, then it might explain what we are seeing. I also wonder if the script might need to run even more frequently because some of the blocks are being found in very quick succession.
I had it running every 60 seconds, now I've set it to run every 30.Notes:
------
These scripts (from version 2.x.x forward) are intended to run every 60 secs. Best results will be achieved
if you configure your server to run them at the same interval. You risk missing new block information being
inserted into the database the longer you set the interval between these scripts running. Database load has
been significantly improved from version 2.x.x forward and it should now be perfectly safe to run these
scripts every 60 secs.
If the script is running less frequently than every 60 seconds, then it might explain what we are seeing. I also wonder if the script might need to run even more frequently because some of the blocks are being found in very quick succession.
I am not sure how to fix the blocks that have not been confirmed, but you might just need to increase the value passed into the $bitcoinController->query in cronjobs/cronjob.php
I have not been able to find where that listtransactions query is defined so I don't know what the value of 240 represents.
Quote
//Query bitcoind for list of transactions
$transactions = $bitcoinController->query('listtransactions', '', '240');
$transactions = $bitcoinController->query('listtransactions', '', '240');
I have not been able to find where that listtransactions query is defined so I don't know what the value of 240 represents.
As far as the FC client goes, that returns the most recent 240 transactions. I've increased this as well, but it doesn't seem to have had any effect.
It seems that the most recent blocks found are getting their confirms fine, but for some reason there's a good amount of blocks that it doesn't seem to pick up on.
Looks like you have a lot of blocks that you will have to manually process -- common problem with the server soft you're using.
Gah...can you shine some more light on this for me? How frequently are your cron jobs scheduled to run? The /cronjobs/README for mmcfe says:
Quote
Notes:
------
These scripts (from version 2.x.x forward) are intended to run every 60 secs. Best results will be achieved
if you configure your server to run them at the same interval. You risk missing new block information being
inserted into the database the longer you set the interval between these scripts running. Database load has
been significantly improved from version 2.x.x forward and it should now be perfectly safe to run these
scripts every 60 secs.
------
These scripts (from version 2.x.x forward) are intended to run every 60 secs. Best results will be achieved
if you configure your server to run them at the same interval. You risk missing new block information being
inserted into the database the longer you set the interval between these scripts running. Database load has
been significantly improved from version 2.x.x forward and it should now be perfectly safe to run these
scripts every 60 secs.
If the script is running less frequently than every 60 seconds, then it might explain what we are seeing. I also wonder if the script might need to run even more frequently because some of the blocks are being found in very quick succession.
I am not sure how to fix the blocks that have not been confirmed, but you might just need to increase the value passed into the $bitcoinController->query in cronjobs/cronjob.php
Quote
//Query bitcoind for list of transactions
$transactions = $bitcoinController->query('listtransactions', '', '240');
$transactions = $bitcoinController->query('listtransactions', '', '240');
I have not been able to find where that listtransactions query is defined so I don't know what the value of 240 represents.
I joined last night around 2AM with about 13,000KH power and have only been paid out on about 24FC so far. Is anyone else experiencing this? Not sure about the lag time for new miners on this pool.
You're shares will only be counted after the block has been confirmed (120 confirms). That can take up to 6 hours.
Hi guys, I'm not sure why those current round share numbers are so borked, or why so many of those blocks aren't getting confirmed. I'll be looking in to it today, if anyone knows why this is going on, feel fee to let me know. Thanks!
I'm not sure why this is happening, I'll be looking in to it today and will keep you guys posted.
Is it just me or is the current round shares saying Pool Valid: -355506....what gives?
I'm not sure why this is happening, I'll be looking in to it today and will keep you guys posted.
Looks like you have a lot of blocks that you will have to manually process -- common problem with the server soft you're using.
Gah...can you shine some more light on this for me? Where is the admin ? .... please fix the problem with unpaid blocks ...
I'm here, I'll be looking in to this today. 
I joined last night around 2AM with about 13,000KH power and have only been paid out on about 24FC so far. Is anyone else experiencing this? Not sure about the lag time for new miners on this pool.
Where is the admin ? .... please fix the problem with unpaid blocks ...
Jump to: