Gone and done it https://mega.co.nz/#!wNtDTS5T!0AYfDx8bOUPPsa1w8eHJvE6p07eTvvl5TDuLYKhrz14
Doubleclick a pool and it bans all entries of that pool until you doubleclick it again or restart minercontrol. Useful when some pool borks out, like Yaamp did today

Source: https://github.com/KBomba/MinerControl-KBomba
I kept the donation addys the same, so if you want to donate to me, my BTC addy is in my signature

I also added dynamic switching to the mix. If the price difference between the best entry and currently running one is very large, it will switch to it faster than the "switchtime" setting.
Dynamic switchtime = "switchtime" / ((best entry price / currently running price) ^ "dynamicswitchpower"). (if anyone knows a better formula, feel free to tell I'm not a mathematician)
Add these to "general":
      "dynamicswitching": true,
      "dynamicswitchpower": 2,
At 200% profit, it will switch at 1/4th of the original switchtime, which is 1min at default values (4min). 150% => 1min and 46s, 120% => 2min and 46s, etc

Under Yaamp settings, I added "balancemode". It defaults to 0, which is "Total Unpaid", the total of all unsold and sold coins, which also was default behavior up to now. I prefer to set balancemode at 1, which will give me "Balance", the total of just the sold coins. Looks more like a Nicehash balance that way But needs some time to build up if you're new to Yaamp probably. More values here: Github

It's not far away

Total time logged in: 21 days, 8 hours and 17 minutes.

That's a pretty old card, it will not reward you anything big in comparison to electricity (and headache ) costs, so be prepared for that.
Anyways, I'll reply with a quote ^^"


I'm a cuda-fanboy, don't have any AMDs at all, but afaik X11 (and sometimes X13) will be the most profitable for AMD miners Look for the Wolf0 kernel, it will give you better rates IIRC.

Lol, maybe a year ago Nah, try XMG, it should give you a block someday, since there are no GPU miners available for their algo, unlike Vertcoin.

That's the spirit Anyways, what GPU do you have?

Wouldn't be the first time GPU-Z is wrong on anything
Check your GPU here, under "Cuda-Enabled Geforce Products": https://developer.nvidia.com/cuda-gpus
But I can already tell you a 780ti is compute 3.5 and a 760 is 3.0

Hah, he should add it to --help Anyways, if I see it right, it's -a bitcoin

Or use my compile https://mega.co.nz/#!ZI8UUZzb!jV7smY-l0MxoWvHRLkscj-Q6L9acsfNKnDJncDy-5-8

It isn't x2... Again: http://cryptomining-blog.com/4219-the-new-nvidia-geforce-gtx-960-mining-performance/
Comparison 750ti/960 is in that link

It gets even worse the older the thread is... and this one is verrrry old
I didn't know there were other cudaminers before the real cudaminer (and now ccminer) ^^ Thanks for reviving this one

Great tip about that physx. Didn't know that.
So on-GPU won't work at all, everything offloaded to CPU?
Can't you assign another GPU to do the PhysX? (if you have a spare 750TI, best Physx accelerator ever)

Yeah, but it's still possible That's why we really need --cpu-priority and --cpu-affinity to robustly set them up through cli & scripts. There are already workarounds for this, but built-in is always better, easier and more straight-forward.

Yep Unless you assign it to a specific core (if you have more than one on your rig ), so you still have cores left that won't be locked.
Chances of locking up are low though, but it is possible. One would want to eliminate as much point-of-failures on a continuous mining system.

I'm gonna keep repeating it: setting to high, higher than high, stoned high, doesn't make a difference. Setting it to realtime does, but might lock up your system.

Get on IRC Also, post right above yours

They set the process priority and affinity Realtime priority (5) will grant full priority of your miner over any other process on your windows. This boosts your speed a lot, I've seen quark go up by +200kh by using realtime priority.
Setting affinity will lock it to certain core(s), so the threads don't hop around too much. If you grant realtime priority to a process, it could lock/freeze up your system (nothing else can kill it), but if you assign it to only 1 out of 4 cores, other processes (like taskmgr) can run on the other 3 cores and kill it, if necessary.
Also, if you run cpuminers next to ccminer, or something else that's cpu intensive like av scan, and they run on the same core(s), they'll interfere with eachother. You don't want to lose 200kh quark per 750ti because some funny CPU only coin you're mining next to it
I've also seen on some cpuminers/algos that setting up a different process per CPU core, and locking them to an assigned core, they perform much better. This doesn't mean it will necessarily boost ccminer speed (at the moment), but it doesn't hurt it at all to say the least. I'd like it mostly because it's much easier to manage your low-level-hardware miners.

I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity

Sp, can you take a look at tpruvots latest additions? (KlausT has them too already)
Setting --cpu-priority 5 (sets it to realtime from command line whoohoo) gives a nice extra Even "highest" priority doesn't get this boost on windows.