Quote from: doktor83 on June 08, 2018, 07:13:27 AM

Quote from: hesido on June 08, 2018, 06:55:24 AM

Quote from: wudafuxup on June 07, 2018, 11:46:07 PM

Coin switchers are a meme. Very difficult to properly monitor accurate market data + nethash spikes with low latency.

Certainly that was not the case for heavy coins. You could mine 5 units per hour in one half of the day, 8 units in the other half. You may guess which half is the better choice.

I am going to re-think is integrating coin switching worth the time and effort because its not as simple as i thought.
First idea was to use minecryptonight.net API which is so easy, just give it your hashrate and it returns the most profitable ($$$) coins.

But when you mentioned switching by difficulty, etc here things got more serious Cheesy

As you are already working on that proxy, i will probably leave it to you, and i will focus more on the 'miner things' , i should find the cause of why does kernel recompilation sometimes creates 'better' kernel. There are a lot of parameters used internally, not visible to the user.
I have to go back to debugging the opencl kernel, this will take some time.
Also i want to make miner more stable, as some users are experiencing stability issues i can't reproduce

Back to the proxy, i did not check it out, but as in the current state, it can to coin switching for SRBMiner too?

Also some info :

Next version in a day or two , with support for the upcoming Masari and Haven forks. It's already integrated and working, but i want to be sure that everyting is ok before releasing the new version

I used the proxy with SRBMiner with good results, and tested with XMR-stak also. However, I need to add TLS support and that means I have to learn more stuff. I could also employ the max allowed difficulty in the pool switch too, it may be another parameter in the coin-switch (auto coin switch is in the works, not working

). When thing get stable enough for SRB (it never does, it's a continuous fight against new drivers and windows updates and new algos) but if at all, coin switching through job json would be super awesome (without miner restart ;=) ), to overcome the namespace problems (everybody is calling some algo differently) since there's no set standard for algo names, you could go with e.g. "_SRB_powtype": "CryptonightV7" , so the proxy can add that to the job json..

But in future if the algo names follow standards, pools can send the "powtype" for any job, this way they can signal miners any algo change due to forks etc. with no problems, so hashrates are not lost with people trying to guess when the fork is going to happen, e.g. they could send "CryptonightHeavy" for block 30000, and "HavenAlgo" for block 30001 so the change would be seamless (even for miners that would need a restart, they would restart at the proper time!), this would be very good for a comfortable transition to new algos. A man can only dream Cheesy