Hey guys, I lurk and have been poking around but I don't know python so I haven't been able to look at it as much as I would like.
Anywho, I have a development/feature idea and feel free to relocate to somewhere else if they are supposed to go somewhere else but it is for papampi's wtm auto switcher. It works well, but I was thinking about something that could possibly help in certain situations.
Let me know if I am being an idiot and/or overthinking this.
I timed the switch between coins when a new coin is found and used that to extrapolate from the set switching interval (default 3min) that in order to overcome switching losses from downtime that I would need to set the minimum difference to 9% (up from 7 default). Now the situation I just observed casually was ZCL holding at about 7.5% greater profit than the current coin for roughly 15 minutes (5 checks) before going to 15% higher and the rig actually switched. My idea would be a degrading minimum switching percentage kinda like what miningpoolhub does with their switching algo. The reasoning behind it is that with every subsequent check where the coin doesn't switch would actually lead to a lower minimum difference required to overcome those switching losses. You want the switching minimum to be high in the beginning so you aren't chasing a 7.5% increase with a 9% loss from switching. In my case. the actual 3-minute switching loss would be 8.4 initially and drops to 4.7% by switching every 6 minutes. 3.1 every 9, and on and on. Would it be hard to implement setting an initial minimum switching and then set a degrading percentage that it goes down by every 3 minutes until it goes to a lower minimum switching level? In my case, i would like after a few iterations of being on the same coin that it would go down to say 1% difference and would switch easily. Then start back over at the upper minimum switching percentage and degrade all over again.
Thanks guys,
Ryansgt
I think I understand what you want to do, but your explanation is too vague.
I will try to summarize more simply:
you want a fluctuant checking time for the script that will be modified according to additional and / or specific parameters of each coins you choose ?
Could you explain more clearly through three examples of Coins please?
For example, imagine a scenario that fluctuates between ETH, ZEN, GBX or FTC and XVG. Describe each step separately as a list.
I am not a python developer, and unfortunately, I think that papampi is not very comfortable with this language either. Papampi forked Scott Alfter's MPH script to use Whatomine.com.
But maybe users will know how to give you what you want.
Sorry, got a bit busy at work. Let me see if i can describe the situation a bit better.
First things first, switching losses: We know that the miners have some downtime due to killing, restart, and then ramping up of the miners. If that takes 30 seconds and we have the potential to switch every 3 minutes, then the switching loss (assuming it does actually switch every 3 minutes) would be 30/180 or 16.6%. This means that any new coin to switch to must be >= 16.6% more profitable or we are losing more from not mining than we are gaining from switching to the new coin. This obviously changes if we raise the switching interval to say 6 minutes. then the potential switching loss is 8.3%.
We have to set the % high because we would be getting screwed if we have coin profitability switch rapidly, like every 3 minutes. The problem is, with that high of a minimum profit switching percentage it stays resistant. For example, say a coin stays profitable(with subtracted difference included) for 15 minutes. In the example I gave in my original post, I was mining I think zec and for the entire time it was mining I saw that zcl was actually 7.5% more profitable but it wasn't switching because of the high minimum switching percentage. When a coin continues mining, either through being denied a switch because of being below the minimum profit difference or simply through being more profitable, we are effectively raising the switching interval, instead of every 3 minutes, it becomes 6,9,12, etc. What I propose is a minimum switching percentage that shrinks based on the number of times that the switching interval has passed. If the initial percentage is set at say 9%, the first time the profit is checked, the new coin would need to be >9% more profitable. 2nd time, 4.5% more profitable.
I actually did think of an even easier way (for the user) to implement this. A user could time how long it takes for their rigs to switch and that + the switching interval that already exists could be the input. The minimum switching percentage could be calculated as a function of those two values and a count of how many times the profit switching interval has passed.
Presupposing the time to switch is 30 sec, the interval is 3 minutes, and then a count is maintained of how many times the profit check has run.
s / ((i*60) * c)
30 / ((3*60)*1) = 16.6
30 / ((3*60)*2) = 8.3
30 / ((3*60)*3) = 5.5
So as you see, the longer the coin stays profitable, the easier it is to switch. In my previous example above, mining the zcash for that long is a mistake. Skipping the first time is good because it wasn't above the level where witching losses would be overcome by the increase in profit. Same for the second. By the third time it resisted switching because of the minimum switching percentage, we are missing out on 2% that we would gain from switching at that point. The longer it stays doing that the more inefficient it gets.
After a successful switch, the count would be reset back to 1 and it would go back to being resistant to switch again.
I think Miningpoolhub does something similar internally with their hub feature though I am unsure about their implementation.
I was actually gonna use this as an excuse to get more acquainted with python. I am used to php and so far python doesn't look to be crazy so I will see if I can't get something drawn up. I am sure there are some much better coders out there with me that won't get hung up on syntax the way I most like will though. Setting up a dev box atm.
Let me know if this makes sense
Ryansgt
I dont think its a good idea because your scenario make switcher switch to dropping coins easier.
Coins profitability has some kind of sine graph, it start losing difficulty and gain profitability then all the switchers out there start switching to it and its difficulty start to raise and profitability starts to drop.
When we use constant difference value for switch new coin either is on rise and will reach the difference point to switch to or it has a jump and now dropping and it wont switch to it.
With your scenario our switcher will switch to a coin while it may be on its losing profit cycle and then it will switch to a new coin much faster because last coin is on its dropping cycle of graph.
Example on a coin that jumped and then losing profit (constant rate will not switch)
We are mining ETH with 100% profitability and difference set to 10
1st check, , zen difficulty drops and profitability raise to 102. No switch.
2nd check, difference should be +5.5, zen raise to 105. Still no switch.
3rd check, difference should be +2.25, zen difficulty raise and profit drops to 103, now it switch.
4th check, more difficulty raise and profit drops to 95, still mining zen, difference should be 10 to switch now.
But with constant rate it will switch only if profitability rising to reach the point and not while its on the dropping cycle.
Its not good to do more and faster switches, I tried to add a minimum mining time to prevent fast switching and having lower difference but that makes the script unstable,
I'm still working on a way to make it work. (will send you latest test in PM)
