Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 330. (Read 837101 times)

How did you donate? I have yet to see an address?

I FINALLY MINTED A BLOCK!!!! (sure, it was only namecoin, but I love it! Need more hashes...)

Donation sent. Thanks for your work Doc ! 

We have had downtime and a high number of rejected proofs of work (stales) in the last days. The old server is on its last legs now. It can no longer keep up with the load produced by so many miners. There's a new server standing by to take over.

I wanted to implement support for backup pools in the BitMinter client, and I wanted to announce the move ahead of time. Sadly the situation is now that we are running out of time. The old server is almost constantly slightly overloaded. This is producing high stales and a little more load could cause more downtime again. Therefore it appears the best move is to get over to the new server as quickly as possible. I will make the switch after I have prepared everything the best I can so that the switch can be done quickly.

You may want to set up a backup pool so you don't lose any mining time during the server switch or if the old server has any more problems before the switch. I understand not everyone will be able to set up a backup and I will try to make the switch as quick as possible to minimize downtime for miners.

Sorry for the inconvenience. Things should be much smoother on the new server.

Switching servers sooner than later sounds good to me.

Well look at the live stats... i like the shift stales 

Another reason to switch earlier is our 2 day avg is ~110GH/s.  So updating the thread title to reflect that might draw in more hashing power. Of course you probably don't want that till we are on the new server.

The faster you can make the switch the better.

Thanks, added your thoughts to my existing plans for messages.


Welcome!

Dr. H it is your call but I wouldn't wait.  I moved my rigs to backup server so personally a move to new server would be optimal for me.  Waiting seems counterproductive.  Hashing power is on an upswing and given how tough it has been to grow the pool you probably don't want to lose the momentum.

Great!  My 2 Ghash/s which used to be lonesome cowboys looking for entire blocks, are now mining at BitMinter. 

You're the pool op, Doc; ultimately it's up to you. If your opinion is that the old machine is too crippled, by all means switch earlier.
I believe most sensible miners do have a multi-pool contingency plan set up?
The newbs... will be the newbs. They'll get hit whatever you do.

Personally, I switched pools for 12 hours when stales had spiked and all my rigs dropped temps by 1°C. I'm back now - provisionally.

I guess not.  Probably better to do it sooner than later now, before people run away because of the stales or slow response.
But here is something you may want to write down on your ever growing todo list: notifications, so you can let people know the server is going down (not everyone reads this thread). You could this in the miner app, email or once you have implemented it, perhaps SMS. I know you already have twitter and IRC, but thats not going to reach the majority either.

It's because the old server is still struggling to keep up.

I spent yesterday preparing the new server while at the same time trying to keep the old one afloat.

Unfortunately the new code had a rare deadlock in it, so I had to restart the back end 2-3 extra times yesterday because it would seize up. I did not want to go back to the old code because it gave higher stales. Luckily I quickly located the problem and the new version seems to have helped a lot with stales. At one point we were over 3% BTC stales. Now with the new version it seems to manage to keep it around 1%. It should be lower stales than ever on the new server.

In the middle of all that I got the new server almost ready. Now the question is, when it is ready, is there any point waiting until saturday? The old server is barely limping along, giving high stales and making miners unhappy. Not sure how long it will take to make the switch. But I don't think it should take long. Stop everything on the old server, dump the database, copy over database and wallets to new server, import database on new server, then start everything up.

  no idea what the problem is but the stale rate is still not there where i want to see it.

At this point, CPU miners would be working at a loss anyway.

I see no reason that dropping support for them would upset anyone.


(Also, I leave for one morning to play WoW, and you guys push 120 and solve a bunch of blocks. I should play more WoW.)

I find the idea of banning CPU miners from pools appealing.
CPU mining is not even supported by default in the newest versions of cgminer... no good reason why pools shouldn't drop CPU-mining support in their own best interest.
The fact that such an approach would hit botnet overlords with a ricochet just adds more value to the idea.

I agree, (CPU miner ban)

btw everything is now smooth as silk again..

come back to the pool, maybe its something you are doing? hehehe

I guess I should have said getworks.  A single worker requesting 100x the normal amount of getwork is equally "hard" on the server as 100 workers.

With ntime rolling, and long polling high end GPU are very efficient they get 1 (sometimes >1) share per getwork on average.

So 1 billion shares ~= 1 billion getworks.

However CPU are horribly inefficient.  They rarely finish a getwork before it becomes stale thus they end up requesting multiple getworks per share.  For example a CPU getting 2 MH/s per core will take on average 35 minutes to find a share.  However on average every ~4 minutes their is an LP.  so it will take up to 8x as many getworks to provide work for an equivelent amount of hash power.

So 200 GH/s made up of nothing but 5870s vs 200 GH/s made up of nothing but Pentium 4.    A small pool can handle the former and even something like Deepbit feels the load of the latter.  Even Tycho has to routinely ban/block botnets not because of DDOS but because their large but inefficient presence is brutal on the server.

The sad thing is there is a "solution" but it must be made by the CPU miner.  Use a custom built proxy server.  It requests 1 getwork (4 billion hashes).   The proxy server then chops that up into 100 "baby sized" getworks to fuel 100 CPU cores.  Each "baby getwork" is now 40 million hashes.  At 2MH/s a CPU core will finish its work in 20 seconds.  From the pool server's perspective there is just a single 200 MH/s high efficiency worker.

Doc is working on it !