If you want to make it real simple, try the custom miner at my pool. It runs very well on 6990.

Often being away from the mining machine you'll probably want to set up something like VNC so you can access it remotely. I don't know if I would bother with switching OS back and forth. Just let it run and pause the mining when you need the GPU for something else (or the fan is making you deaf).

With new server and a new version of the pool backend software we can now handle a much higher hash rate than before.

Fire up your miners and let's see if we can keep the server from falling asleep. 

Thanks for all those votes of confidence earlier.

New version of pool backend up today. Big performance improvements. GPUmax took the server to 220 GH/s total and I could barely see any load.

Last problem to fix for the pool to work better with GPUmax is to get better in sync with the big pools. GPUmax uses their long polling regardless of which pool they are mining at (it doesn't watch our long poll at all). This has to do with how work from different pools gets sent through GPUmax to the same miner, and a long poll signal from them to that miner would cause it to throw away all the work, regardless of which pool it is from.

Anyway, that's a GPUmax specific problem. For normal miners we can now take a very high hash rate. So fire up every machine you've got!

As always with big changes on the system, please let me know if you notice anything wrong.

Sorry to hear this happened.

It's inspiring to see how you never give up, though. Best of luck with the re-opening!

It's basically the same performance-wise, because both reduce the amount of screen updates so your GPU can mine instead. If you have 4-5 gauges being updated on the screen you can see some slowdown.

I think starting in performance mode can still be useful though. I'll add it to my list.

Hmm yes, the results are a bit unexpected.

Currently I have 2 (0.08%) rejected and 2,431 accepted in the block rounds. And I have 0 rejected and 545 accepted in the current shift.

I'm not sure what's causing some workers to get high stales still. I'm working on some ideas to lower stales further though.

Anyone who is running BitMinter client and haven't restarted it since we switched server, please try shutting it down and starting it back up. Then it will connect directly to the server in Germany, instead of going to the US and then through a tunnel to Germany. This could improve stales somewhat.

It wasn't when you asked, but it's running now.

First block change 3 stales. Second block change 0 stales. Looking good so far. Block rounds are of course affected by stales from the earlier backend still. But you can see the results of the new backend in the current shift, and faster response to your workers.

Ok, stales went up a bit more now, but still looking ok I guess.

Working on some more improvements.

Yeah, I use screen all the time. For some reason I didn't with this thing and I thought it was only going to be needed a few minutes/hours. I put it inside a screen session now when I restarted it.

Found the problem too. When running with a security manager, the Java virtual machine caches DNS lookups forever. I didn't know that. Java WebStart applications always run with a security manager.

I will see about fixing this problem + fixing GCN support so AMD HD7970 runs properly fast (right now you must disable BFI_INT on those), then release an update for the BitMinter client.

The tunnel from old server to new went down this morning, causing quite a few workers to lose their connection to the pool. It's back up again now and workers seem to be reconnecting. Still through the old server. It's surprising that the old address is still being used so long after the switch in DNS. It appears BitMinter client is among them. I'll have to look into this problem and see if there is a way to force Java to look up hostnames anew.

What happened was that my overvoltage protection kicked in and cut the power to one of my computers. The shell with the tunnel was running on that computer, so the tunnel went too.

I think the tunnel was down 30-40 minutes? My apologies for the lost mining time for those affected.

Yay! All hail Dutchman, the slayer of the beast!


Most likely it was the rate of requests going high enough to hit that bottleneck, causing everything to slow down and stales to occur.

I'm testing the new pool backend version now. I wanted to get it running tonight. But I'm going to let it run overnight to get some more testing on it.

0.53% isn't very good. And somewhere around 160-170 GH/s stales suddenly rise a lot. Next update the back end should run much better.

Add percentages beside the rejected numbers? Good idea. I put that on my list.


Well, it's very useful for me. I can see how much my server can handle, and find bottlenecks in my software.

He pushed up to almost 40 GH/s, then stales started rising.

What I found strange is that the new server isn't breaking a sweat, and still things slow down badly when the number of requests per second goes over a certain point. After watching the logs and numbers for a while I've located several bottlenecks in my programming. I hope to have a new version of the pool back end up sometime tomorrow. It should be able to make full use of the more powerful server.

P4man, nice numbers!

I'm still hoping pool-wide rejects will go down. It might help when miners connect directly to the new server instead of going through the old one. Since the switch, we've gone from 493 connections down to 433 through the tunnel from old to new server. Going down slowly. It may be that some miners need to be restarted to force them the resolve the hostname again and get the correct server.


Yep, at Hetzner. They have some very nice prices. Now we just have to get the hash rate up. The new server is idling too much.


Thanks, it was a big relief!

We have moved from American to German server. In the long run I would like to have multiple servers and probably spread out across the world. But I don't think this should have a big impact. If your round-trip-time went up by 100 ms, that would be 50 ms longer delay one way. I guess that means if you are American you may now get long poll messages 0.05 seconds later. Except the server is much faster, so it's probably faster than before, also for Americans.

This is the new server:


You shouldn't have to flush anything. The TTL (time-to-live) value of 5 minutes should make the cache flush this IP address after it has been stored a maximum of 5 minutes. I was a bit surprised to see this not work properly at home though, took probably 15-20 minutes before I could see the new IP. At the office it worked fine, though.

Server move took 11 minutes. I was hoping just 5-10 min, but not too bad.

Unfortunately there was one problem. During the switch an NMC payment was executed an extra time. A few users now have a negative balance of NMC. You can look up every payment on blockexplorer from your transaction history on BitMinter. If you have a negative balance you will find two payments with the same amount but in different blocks on blockexplorer. Normally the pool should not pay out money you don't have, but you can consider this an advance. It will correct itself after a couple more NMC blocks are confirmed and your balance will be positive again. Let me know if this situation makes you unhappy.

When I switched over I set up a tunnel from the old server to the new, so you can mine even if you use the wrong IP address. I'll take this down later. Currently almost 500 connections going through it. Weird how long new DNS data takes to spread even with 5 minutes TTL. My ISP at home was even serving out the old one after TTL went to zero. TTL went back up to 5 minutes, and still the old IP. DNS is not supposed to work like that! Oh well..

A relief to see everything running smoothly.

Up again. Let me know if you have any problems.

Site going down for server switch. Will be back ASAP.

Finally the end of that long block.

You can see the BIP-16 vote here: http://blockchain.info/tx-index/14971049/d32f30a02a465570db1a4a99743045f8bdad119e417963dbc72a28732d473481

The "/P2SH/" is the vote. Also, our blocks' coinbases start with "BitMinter" to show where they were made. The unreadable garbage is the extranonce and data for merged mining.

Much appreciated, sir.