Remove one 'ni' in minining

Good point, I'll add this.

There's no need to touch bitcoin.conf or start bitcoind for pool; All miners are talking directly to pool server. Everything you need is miner (jgarzik's, m0mchil's or Diablo-D3's, worker account on pool and correct command line arguments.

http://mining.bitcoin.cz/stats/?history=100 . Stats will be also improved when new features (from profile) will be enabled.

Just now I migrated database to new server. Tomorrow I migrate the rest of pool. It should definitely solve all stability and performance problems.

You are using puddinpop's miner? I didn't tested it, so I cannot promise it work at all...

Teoretically, yes, losing share can lead to losing blocks. But in this case also 'non-winning' shares are lost, so it should not change final share/block ratio. I'm working on it with some guys, so I hope we will find a reason soon.


You are right that it can be a little confusing, but it is how things works; General purpose miners (m0mchil's, Diablo's, jgarzik's) don't have an idea that they aren't solving full difficulty hashes...

Yep, it is because server is overloaded. I'll move pool to standalone server, because it is pointless to tune Drupals, Joomlas and other stuff lying on current server to not interfere with pool...

How is this related to pool thread? Those blocks was not found by pool.

Well, people are suspicious when pool find blocks too fast, they are suspicious when pool find blocks too slow; You probably need block exactly every 3-4 hours, right? :-)
I found two block in a row with single 5970, so numbers above for 5ghash pool are not so exciting for me. It is only kind of luck.

Edit: Oh, sorry, now I see those blocks are not generated by pool. I was confused because FreddyFender submitted this comment also to pool thread.

Stop this conspiracy. DDoSed was completely another service, not pool itself. And I already know who was the attacker - it was my colleague (tester), playing with new version of performance testing tool. Yes, he was so dumb that he pointed testing tool @ 100mbit line to my poor personal VPS :-/.

I know about this disbalance, too. I'm logging _all_ shares for few days ago (actually it is 355303 logged shares) and I'm working on uncovering possible problems. This can be still explained by probability and luck, but I want to be sure there is nothing bad behind those numbers.

To your question - yes, all shares are unique, except few re-submitted from miners when pool was unstable (yes, sometimes is database overloaded; I'll move pool to standalone server soon to avoid interferences with another services). But those re-submitted shares was not count twice.

So let me play with gathered shares, I'll try to find any possible problems here. I'm also interested, if there is anybody else with large hashing power to ask him if their miners have correct probability distribution.

I'll also publish share logs soon to allow other people to review share stats by self.

What miner? What crashes? Do you have some traceback/error message?

I'm going to do a system kernel update. Service will be down for few minutes.

If your miner won't reconnect automatically after then, please update to newest miner version. If you already have newest version and have troubles with miner stability, please ask developers.

I just set up high availability application cluster on the server. That means I will be able to upgrade application without any service outage.

(Thanks to amazing Nginx server I set up HA cluster without a second of outage, too :-).

Update: Huh, pool is currently down because of DB memory problems. Sorry for troubles, I'm working on it. That's Murphy law; first real pool outage few minutes after announcement of stability improvements :-).
Update: Memory problems fixed. Service was down for 10-15 minutes.

OK, I added block# to stats page (in next release).

What specific stats about current block are you missing? Block history table is, ehrm, block _history_. Operational stats are above. Btw next block number is in my opinion non-relevant for pool stats.


Of course miners have up to date information. Miners are asking pool approximately every 5 seconds for new job to crunch.

What's their timestamps? 502 means service is temporary down. It happen time to time. Today it was because I had DDoS attack on server (another service, but server load was >30 for short time). I'm sorry for this, but re-submitting shares again in short period should solve it.

So, email was returned with "550 No Such User Here" error. Please PM me some working mailbox...

Hey, I resend confirmation code to your mail again. Please also check spam folder and so.

All users: Please update to newest version of your miner!

jgarzik's and m0mchil's miners fixed stability problems when pool is in maintenance mode or temporary down. This should prevent crashes as today, so you won't need restart miners so often.

Diablo's miner fixed important performance issue. Share count will go higher than with previous version for many users.

If you are user of jgarzik's CPU miner, try also new 'cryptopp_asm32' algorithm. It is working well now and improve performance for many users (hashrate is same or better than in official bitcoin client). Thanks jgarzik!