|
Thanks for update, good to hear about progress... Looking forward SEPA transfers soon :-).
|
|
|
|
Why is the reject rate THAT hight? so far, I have 49 accepted and 39 rejected!
I don't have enough info, but - of course - it does not sounds healthy  . What miner parameters are you using? Something might be wrong here... |
|
|
|
Bad miners simply do not connect at all. Ever. Miner before that would get ZERO connection until i switched from api2 to api.. Pinging them works great though.
What miner are you using? There were such troubles with phoenix older than 1.50... |
|
|
|
I have 3 workers, each one running in a 5850 with phoenix/phatk and all pointing to api2.
I have just seen that two of them have the same amount of submitted shares after 48 hours (last reboot), but one of them have 3 times less than the other two in the same time. May be a problem connecting to the pool ?
BTW, what is an approximate "right" value for stale/invalid shares ? I'm having about 1.5%
Do you see any error messages in the 'bad' miner? Idling messages or higher stale ratio? If it is just lower miner performance, it might be some hardware issue. But hard to say without more info... 1.5% is in expected range. |
|
|
|
api2.bitcoin.cz isn't letting all of my miners connect. it took me hours to figure out to try api.bitcoin.cz
you should really say why api2 exists, newer server vs second server for more connections
Actually there's no difference between api.bitcoin.cz and api2.bitcoin.cz. Your miners should work with both URLs. Can you try some network tools to analyze connection between you and servers? Ping, traceroute, telnet (mainly if server let you open the connection to put any request). |
|
|
|
so days like these are just badluck and nothing to do about it but to increase the overall performance?
Increasing overall performance will just make rounds shorter, but it didn't help with having rounds many times longer than expected average. Having many hours round is mostly psychological problem, it does not affect expected payout in longer timeframe (in days). Personally I'm completely checking pool status everytime when such long round happen, but I'm perfectly calm when I found it isn't any technical problem, but just a "luck". Over a half of a year of running the pool learnt me that one round does not mean anything. |
|
|
|
It so happened that traditionally almost every pool for some reason has a setting 'send me money if my balance is above <such and such> number'. Perhaps Slush have done this in his pool half a year ago and everyone mindlessly copied it.
Half a year ago, one bitcoin was almost nothing and I didn't want to spam every mined coins to wallets. For example, some users used (and they're still using) threshold in tens of BTC, to keep their wallets 'clean'. Actually I'm thinking about some high limit, because I don't want to keep high deposits. But still, everybody can set up threshold as low as 0.01 BTC, if he don't want to risk his BTC, so I don't see any issue in this. By default, threshold is already 1BTC, as you're proposing. Today there's no reason to not pay all decimal places, except that somebody have to code&test it . |
|
|
|
About screening blocks - at this moment there's no known algorithm to improve probability to find a block faster than is expected average. Ideas like "change block when round is extra long" does not work , every attempt (every nonce change) is almost perfectly random. |
|
|
|
why did we got yesterday only half of the reward?
There is still no other answer than "the probability" . |
|
|
|
I cant, i manually fixed many glitches in the original data, so i'm not going to delete it , too bad but 1h of missing data isnt a disaster.
bitcoincharts is providing only limited history (I think it is 3 days), so if you're mising data in longer history, don't delete your scid file  . |
|
|
|
Hello, difficulty!
But a difficulty raise is just about 13% - I think it isn't a reason for a 6 hour block.
Actually 6 hour block is still in "sane" range, with current difficulty and hashrate. It is still about probability - as far as I can tell, there's no technical problem in the pool. |
|
|
|
On a 5 hour block.. Wonder if this one will be invalid too! ?
Fortunately not . |
|
|
|
Or you could just lower the threshold to your current balance?
0.1 is the lowest I think. If I stop mining anything below that won't be sent to me. Not much, but every little thing counts. I'm working on the upgrade. Soon payouts will not be limited to two decimal digits |
|
|
|
We got a 9 second block! |
|
|
|
Please PM me your IP and pool user name, I will double check whitelisting. How long it is blocked? |
|
|
|
|
We are under attack, bear for the fight. One backend just had loadavg above 12.0.
EDIT: ok, I think that problem is fixed now. But I will keep an eye on that. Some of you might have lost connections, but your miners should reconnect automatically.
|
|
|
|
|
OK, the rewards were recalculated. To compansate all moral damages I don't take 2% fee for rounds 6933 and 6934, but instead I give you 1 BTC extra. Those rounds are worth for you 51 BTC each.
If for anyone the rewards for those two rounds were not recalculated correctly, please report here and I will fix this tomorrow.
|
|
|
|
|
It is a problem with SQL, after so long use the share table reached its all time limit. This is not related to 5 hour round, but to total pool uptime (starting from december). Those shares were not counted in database in fact. Fortunately all shares are also counted separately on each backend, so I only need to merge this data from backends now.
|
|
|
|
Slush, you on this?
It looks like a problem with www cache. All shares are being logged on all backends, so don't worry, they are counted. Recalculating reward later is just a one liner. |
|
|
|
Will you ever consider adding full decimal payout
I'm very busy in those days, but I almost finished testing of newest bitcoind (with my custom patches), which will make this possible. As new bitcoind will be used by the pool, I'll enable full decimal payout - in fact it is one line change... |
|
|
|
|
Show Posts
