Nice tool. Good work.
Just one little feature request: Auto-tuning for hash rate.
Pseudo-code:
I chose 5 minutes and 5% because I like the reaction that gives. It isn't too jumpy but still follows reasonable fast. A "half change" is an hour and a "full change" takes 12 hours. However, to avoid flickering when two algos are very close, a >10 minutes switchtime may be advisable.
The optional block is to recover deteriorated values. That way a "bad" pool won't kill an algo for good. With this enabled algos might flicker somewhat if the configfile speeds are (much) too high, or not recover if they are too low, so the user should have an eye on the auto-tuned values for a while and adapt the config file if that happens.
Just one little feature request: Auto-tuning for hash rate.
Pseudo-code:
Code:
@startup (all algos):
speed = read_cache_file()
if (speed.remember != configfile.speed) {
speed.remember = configfile.speed
speed.current = configfile.speed
speed.max = 0
}
// to reset the speed just change the value in the config file
@every 5 minutes (active algo):
if (activity.accept > 0) {
speed.current = (speed.current*95 + activity.accept*5) / 100
}
if (speed.current < configfile.speed and speed.current > speed.max) {
speed.max = speed.current
}
@every 5 minutes (inactive algos) (optional):
if (speed.max > 0) {
if (speed.max > speed.current) {
speed.current = (speed.current*99 + speed.max*0.9) / 100
// need to test if 0.9 or 0.95 or 0.85 works better
}
} else {
speed.current = (speed.current*99 + configfile.speed*1) / 100
}
@every 5 minutes:
save_cache_file()
I chose 5 minutes and 5% because I like the reaction that gives. It isn't too jumpy but still follows reasonable fast. A "half change" is an hour and a "full change" takes 12 hours. However, to avoid flickering when two algos are very close, a >10 minutes switchtime may be advisable.
The optional block is to recover deteriorated values. That way a "bad" pool won't kill an algo for good. With this enabled algos might flicker somewhat if the configfile speeds are (much) too high, or not recover if they are too low, so the user should have an eye on the auto-tuned values for a while and adapt the config file if that happens.
Two problems with doing this.
You can't get the hash values from NiceHash because if you have more than one miner running you are seeing cumulative values rather than for one miner. Also, the accept/reject rates jump around a lot and are not reliable gauges of actual speed.
You can't get the number from the miner itself as there is no communication between NHC and the miner. NHC can start and stop the miner but can't see what is happening inside as it is a separate program with no IPC mechanism to communicate out.
It would be nice to auto-tune hash rates but I just haven't seen a good way to do it, which is why the program can start/stop a single algorithm for doing this type of testing.
need to add this exception if all the prices are 0 
