I put the new version into production and it didn't run very well so I switched back. Have located an issue that I'm looking at now. Unfortunately it's very difficult to test parallel execution of code. Perhaps in the future I can set up a test server and get enough miners testing there to lure out race conditions and other nasty bugs that are difficult to test for.

This new version splits requests into two types. Miners with OK efficiency are served by 7 CPU cores as quickly as possible. Miners with very low efficiency are served by a single CPU core. This would be CPU miners, buggy miner programs and DoS attackers. Normally the slow queue will be fast enough, but if there are too many requests there then they will slow each other down. Unless it is very extreme it should not affect the rest of the pool.

The new version is running smoothly. GPUmax runs and other big miners are at high efficiency.

Also, some users are having more rejects after rollntime was switched on. If you are having problems, please let me know which miner you are running and how many rejects you get (over some time, like a long block). Then we can look into improving it.

Rejects on the namecoin side are ridiculously high now. I suspect this is because of a combination of rollntime plus some miners ignoring long polls with namecoin block changes. They will continue using rollable work that is stale on the namecoin side perhaps several minutes after a namecoin block change, which will result in many many rejects.

When using GPUmax this is exactly what happens with the namecoin rejects, as GPUmax only observes bitcoin block changes.

Not sure it's worth bothering with much, though, as namecoins are not worth much anymore.

Edit: Some rejects were caused some hours ago by restarting the mining backend to get the new version up and running. That's normal and nothing to worry about. Bad thing is if you are still getting a high reject percentage.

ill be shutting my gpu's down sometime this week, after i get one more Jalapeno ordered. it will be nice to get a small power bill again i think ill leave one rig running and set the donation to 100% though or the good Dr could set up another worker and ill let it mine for him

Staggered start of devices when multiple devices are started with the button on the status line or the "total" display's start button. Should give a smoother start up of (multiple) BFL minirigs.

(quoted from other thread)Doc, this change is awesome. Starting up BitMinter for my two mini-rigs is a single click now instead of spending 3-4 minutes manually re-adding FPGAs as they drop offline over and over during the startup. Thanks!

ill be shutting my gpu's down sometime this week, after i get one more Jalapeno ordered. it will be nice to get a small power bill again i think ill leave one rig running and set the donation to 100% though or the good Dr could set up another worker and ill let it mine for him

Thanks - much appreciated

You can just set 100% donation and leave the last one mining. Remember to change the setting when the Jalapenos arrive. Alternatively the test account used by the test edition of the BitMinter client (http://bitminter.com/test) will donate everything to the pool. Username Test, workername Test, password Test (note the capital letter everywhere).

Doc, this change is awesome. Starting up BitMinter for my two mini-rigs is a single click now instead of spending 3-4 minutes manually re-adding FPGAs as they drop offline over and over during the startup. Thanks!

Happy to hear this works better for you. Fefox requested this feature because of the issue you describe. Not sure why it would be so messy starting all devices at the same time. But as long as this works better...

Also note that automatic rescanning for FPGAs is back in the options. This in combination with automatically starting devices when they connect (also in options) will help keep things running smoothly even if a device should drop off and come back.

Edit: There's definitely a problem. I just tried with -u Test -p Test, either with CGMiner 2.6.6 or 2.7.5 on port 80, it still doesn't work.Edit2: With the Java BitMinter client there's no problem, but I lose 100 MH/s by mining with it ;(

I was going to implement getblocktemplate. I don't see the point in also having Stratum. But if some miners support one and some the other, maybe I will need to support both on the server. Same with the client (after adding support for backup pools) if some pools use getblocktemplate while others use stratum.