I don't know if this is a problem but noticed an error in GUIMiner's console corresponding to socket 111: Unhandled exception (2003, "Can't connect to MySQL server on '192.168.176.137' (111)") You're right this should not happen. How many errors like this do you have?
|
|
|
From 15:14:23 local time to 18:11:21 "Problems communicating with bitcoin RPC"
A lot of downtime for a dedicated line and room with power generator what do you think?
Hm, please: a) when you have some problem, ask. Don't post 'cool' images. b) When you post times and expect some investigation from me, please note what exactly is 'local time'. Pool is working fine, there were some problems between 11-12 am UTC, but this looks like your miner crashed during this outage and didn't reconnect correctly. If I'm right, please report this to miner author or upgrade to newest version (some older phoenix versions don't handle errors correctly). No need to be sarcastic.
|
|
|
Cool
Uhm, so? Your miners aren't working for some reason, that's all...
|
|
|
Quick question, is this normal, considering my average?
Same issue as yesterday, fixed. I'm sorry for troubles like this, I'll watch reward balancing more carefully for those problematic rounds.
|
|
|
It would be nice to have a "server online/offline" on the website.
Best indicator is "Current server load (60 sec average):" on stats page. It is usually around 800-1000rq/s. When it fall to 50 or something, then server is down .
|
|
|
"Problems communicating with bitcoin RPC"
It is usually HTTP 50x status or something like this, so it can be anything on pool side. From internal network troubles, to bitcoind deadlocks.
|
|
|
Too much server down.. yesterday & today (just now) Any attack on pool?
Yes, three days, same time, it is really strange. Pool is up again, it recovered itself. I'm in discussion with server provider if there is everything OK on internal network...
|
|
|
I have now TWICE seen Total Reward BTC drop. This morning I had 0.82xxxx, I refreshed an hour later during the maintenance, and now there are only 0.81507997 BTC total. Is this unconfirmed blocks getting suddenly invalidated or is something lost during maintenance?
Two blocks were invalid yesterday, so twice unconfirmed reward drop for those blocks. Those invalid blocks were not caused by pool problems, but there were more block found in network at same time (for example pool block 4706 was found in the same second as another block which was accepted by bitcoin network).
|
|
|
My problem is that while mining with GUIMiner (latest version), after a few minutes I was getting a lot of connection problems and "server down for maintenance". At first I thought that I was just unlucky but then I connected my pc directly to the modem, bypassing the router, and it connected with no problems. After a bit of searching today I've configured my router (netgear) to trigger port range 8332 to 8338 (the second one was just a guess, the first number I got using Tcpview.exe to see where the program was trying to connect). In the end this seems to have done it. What range exactly should I forward (if any)?
You don't need any port forwarding. Please write me exact times when you see 'server down for maintenance', I'll search logs. also, what's the normal % of stale/invalid shares? I seem to get about 1%.
Yes, that's normal. 2nd: I got my key (wallet thingy) by installing the official bitcoin program which showed a "your Bitcoin Address" And I used that in the "My account" page. Is that ok?
Yes
|
|
|
I still see a very low reward for ~3 hours hashing. Is this normal?
Firstly, reward is not necessary related to time, but to rounds. When pool is very lucky for some time, you can earn 1BTC per hour and in oposite, you can earn 0.01 in three hours. But in this case, this round was affected by pool outage and hourly score renormalizing was skipped, so I'll recalculate rewards again to make it more fair. Edit: better?
|
|
|
After this round finish, I'll recalculate block using share based algorithm to minimize unfairnes in rewards.
Because pool didn't find a block until end of hour, everything fixed up and using share based rewarding isn't necessary now.
|
|
|
Hey slush, you have about 4000 workers. And 800-1000 getworks/s. What CPU does your server have and what is the load?
1x load balancer (I'm preparing second one for ip failover), 4x application servers, 1x database server All servers are virtualised Intel Xeon quadcores and typical load is 0.2 (so roughly 5% of maximum load) giving me enough space for more workers . I'm using more application servers mainly because I'm running more bitcoin daemons and I want to isolate them (they ocasionally have disk I/O peaks, so running them on more servers improve their speed a lot).
|
|
|
It's weird. GPU working at full speed but Estimated Reward is ~0.002 in contrast to previous day when ER was ~0.01.
It is discussed in official pool thread. Please continue here, I'm not watching other forum threads so often...
|
|
|
It looks like server failed during the hourly score recalculation process. I see a very large total round score but pieces got by my miners for shares they found are tiny.
Damn, you're right. After this round finish, I'll recalculate block using share based algorithm to minimize unfairnes in rewards.
|
|
|
Whoa fast replies, I love night owls!
It's 1pm here:)
|
|
|
naa its doing the same yo-yo thing it was doing yesterday
Slush has disappeared completely from bitcoinwatch.. it's completely down. Bitcoinwatch is downloading hashrate from my stats page. I turned off website for a moment, because of investigating troubles. So that's reason why bitcoinwatch displayed zero hashrate. Actually pool was not completely down, but majority of users had connection problems. It looks like troubles on provider's internal network and I'm solving it with his support. Pool is back up, but we're still finding any reason for network lockups to prevent outages like that for the future.
|
|
|
Looks like there are troubles on provider's internal network. I'm actually tracking problem with his support. Right now pool is up again, but we still didn't find any specific reason for lockups.
|
|
|
Yes, I'm looking for the reason right now.
|
|
|
That is correct in that if you tried to claim if for yourself you would have to insert your address which would change the hash output and render it an invalid solution.
It is even more simple. Worker cannot publish block directly to the bitcoin network, because he does not know block sources, only hash of blockheader, for which he is trying to find proper "nonce" value.
|
|
|
I can see some BTC in Confirmed reward, but in my client, balance's still blank?? So does is take time to tranfer or anything wrong???
Confirmed reward is still waiting on the pool. Once BTC on your pool account cross the threshold (by default 1 BTC), bitcoins are sent to your wallet. If you hurry, please set the threshold to something like 0.01..
|
|
|
|