[9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining

[doublec]

I'm investigating the high stale issue. The recent changes to the pool that might affect it have been:

* Enable X-Roll-NTime
* Rejecting block times outside a specific range
* Statistics tracking

I've temporarily disabled X-Roll-NTime to see if that's the issue. If they're still high I'll check the block time rejection and the statistics.

[1713977617]

1713977617

[1713977617]

1713977617

[1713977617]

1713977617

[1713977617]

1713977617

[1713977617]

1713977617

[doublec]

The pool had a quick restart a few minutes ago to install some stale tracking code. This restart also adds the HTTP header X-Reject-Reason to any returned result that's the result of a stale or other invalid share. This can be used to help identify why you are getting stales. I picked that header based on the getwork wiki page.

[doublec]

A couple of things I've noticed so far:

* I really need to improve longpoll times when bitcoin blocks are found. This is where the majority of stales is coming from.
* One miner is submitting a lot of duplicate hashes. They'll be seeing these as stales and they'll be fairly high. Your username begins with 'e'. If you think it's you, PM me. Possibly you may need to update your mining software.

[purelithium]

my miner keeps disabling your pool because of "stale-on-arrival" work. I'm not sure what that means exactly, but I take it that its not good.

[doublec]

my miner keeps disabling your pool because of "stale-on-arrival" work. I'm not sure what that means exactly, but I take it that its not good.

I'm not sure what that means either. What miner are you using? I'll look into it.

Edit: Nevermind, found code in bfgminer for it. Looking into it.

[doublec]

I made some pool changes to hopefully improve the stale situation today. Let me know if you see more or less stales.

[Bitinvestor]

I did get a lot of stales after you enabled X-Roll-NTime and they disappeared when you switched it off. The pool is working fine for me now. Before the issue with the stales happened we were at about 300 Gh/s and now we're down to 150 Gh/s even with Mt. Red dead for many hours. Hopefully the miners will come back.

[doublec]

I did get a lot of stales after you enabled X-Roll-NTime and they disappeared when you switched it off. The pool is working fine for me now. Before the issue with the stales happened we were at about 300 Gh/s and now we're down to 150 Gh/s even with Mt. Red dead for many hours. Hopefully the miners will come back.

Thanks for the update, I've left X-Roll-NTime disabled for now while I do more testing on it.

I found an issue that was causing stales whenever a bitcoin block was found by the network. At the time the pool learns of the new block there are a number of getwork results still queued to go to miners but have stale block data. These were still going out so a number of miners could get stale work. This may have been the cause of the "upstream sent stale" that someone mentioned in a previous comment. I've fixed this now by refreshing the stale blocks in the queued work before sending them to the miners.

There's still a period of time between when the pool learns about the block, and when miners receive their longpoll result that some miners will be submitting stale work. I've enabled a threshold for this time period where the pool pays out on stale shares for a short time so miners aren't affected by the pools inefficiency in this area.

Another area of stales was when I restart the pool. For a short period miners submitting work had them registered as stale due to the worker log in the pool being flushed on restart. I've corrected for this so no work is unpaid immediately after a restart.

[doublec]

bitcoind daemon on the pool has hung. I'm restarting it now.

Edit: Back up now.

[doublec]

A couple of minutes downtime just now as I updated bitcoind on the server.

[doublec]

Pool is down for a bitcoind patch. Back up shortly.


Edit: Pool is up now.

[doublec]

Another long block, 13 million shares so far. Fun times in pool land!

[doublec]

There was a few minutes of downtime as the pool found a bitcoin block and chugged through the large share database which backed everything up. I've installed a fix for the issue of handling large numbers of shares.

[doublec]

I've temporarily disabled merge mining while I track down a performance issue. The pool is only mining the bitcoin chain at the moment. It is however paying out the other chains from the pools reserve so users don't lose out but alt chain users may notice a hash rate drop on their chain. I'll update here when I begin merge mining the others again.

[biddicoin]

I changed to your pool - lets see how it goes

edit:

is there a big delay between real income and balance check?

I did recheck over the time and the BTC amount is 13% below the amount it should be (PPS BTC 0.0000181) in relation to my hashrate...
(low reject rate)

perhaps I'm too impatient... I'll leave it for 1-2 days and do the calculation again

[biddicoin]

something is wrong there.... I have a PPS of ~ 0.000015 with 1359mh avg - almost no rejects

switched to another pool until I know what went wrong - its not a delay...

[doublec]

something is wrong there.... I have a PPS of ~ 0.000015 with 1359mh avg - almost no rejects

I'm not sure what you mean. Are you saying you are only get 0.000015 btc per share? Can you PM me the username you used and details on what mining software you are using and I'll look into it.

[doublec]

I've implemented a way for users to adjust the difficulty they mine at so large hash rate users can reduce the number of network requests to send results to the pool. If anyone is interested in testing this please PM me and I'll provide details.

[purelithium]

Awesome! Once my FPGA comes, I'll be interested, definitely.

[purelithium]

doublec: I thought you were turning off i0coin mining? It's been over a month since you made the announcement and it's still mining...