[ANN] NiceHash Control 1.1.1 - Auto profit switching control for NiceHash servic

[thquan819]

Please add 2FA Security

[Zels]

Please add 2FA Security

 

[StuffOfInterest]

Please add 2FA Security

Not sure if you read the thread but this program is not part of NiceHash itself.   It has nothing to do with the security on that service.  NiceHash Control is just a tool to help miners and it doesn't make a lot of sense to add more security for miners.  What is the worse that someone could do, mine on your behalf?

[ltc_bilic]

Hmm, right now NH site is down and also their API interface, so NHC can't launch even the backups that I've put in place, you have to manually run a instance.
So -a command is useless in this case  need to add this exception if all the prices are 0

[StuffOfInterest]

Hmm, right now NH site is down and also their API interface, so NHC can't launch even the backups that I've put in place, you have to manually run a instance.
So -a command is useless in this case  need to add this exception if all the prices are 0

That is a problem the program has.  Also stalls really bad if the program is running and then the API stops responding.  I need to make the API checks happen asynchronously to avoid this.

For all prices zero, I have checks in place now that won't mine an algorithm with negative return.  If the price is zero and power usage is defined this would cause all of them to show as negative.  Will have to think of a good way to handle that scenario.  Bigger headache is figuring out which algorithm to mine if everything is zero.  I've been hesitant to add logic for persisting information from the program back to disk but this may be necessary to leave some breadcrumbs in case of an issue.

Bigger issue is NiceHash being down so much.  I wish there was a better way to track who keeps launching DDOS attacks on them so that person or group can be slapped properly.

[ltc_bilic]

Bigger issue is NiceHash being down so much.  I wish there was a better way to track who keeps launching DDOS attacks on them so that person or group can be slapped properly.

 

[DemosMirak]

Just wondering, but what Min time, Max time and switchtime do you guys recommend?

[StuffOfInterest]

Just wondering, but what Min time, Max time and switchtime do you guys recommend?

Right now I'm using 5, 240, and 3.  I think three minutes may be a bit low for the switch time as I'm still seeing it move over for just a few minutes and then switch back.  It really comes down to how fast the miner can load up on a new algorithm.

If the switch time is more than the min time then min time doesn't really mean anything.

I'm not running a backup pool right now so that is why I have max time set to four hours.  With all of the DDOS issues NiceHash has been dealing with lately I'm going to try and set something up soon (using CryptoMining Blog's technique) and then drop the max time back to about two hours so I won't spend too long on the backup pool when the primary comes back to active.

[DemosMirak]

I just wondered, when you said that NiceHash gets DOSed, the API fails as well. Does it give something specific, and if so, could this specific thing be used as a marker of the pools being down, and thus make the program switch over to a configurable back-up pool, and it would then check back as the settings dictate if the NicheHash gets back up.

[StuffOfInterest]

I just wondered, when you said that NiceHash gets DOSed, the API fails as well. Does it give something specific, and if so, could this specific thing be used as a marker of the pools being down, and thus make the program switch over to a configurable back-up pool, and it would then check back as the settings dictate if the NicheHash gets back up.

From what I've been able to glean from the NiceHash thread, different attacks have different characteristics.  Some go against the website, which takes down the API.  Others go against the proxy, which stop new miners connecting but leaves the API intact.  Unfortunately, I don't think there is much we can take from it.

[miner256]

Hi,
Nice work on this.

I moved off NiceHash last week after all their issues and am using TradeMyBit for the moment. I am a Linux user so can't try your tool :-(
I have written a similar tool in python for use on my linux rig (4 x GTX 750 Ti). No graphics of course :-)

I am interested in the logic on how often to switch or not. When will switching cause you to lose any work done before being paid? I guess it is down to the details of the pool but have you looked into this for NiceHash? Some pools will calculate the earnings once a block is found and if you are not mining at the time you get nothing? Thoughts?

Just for fun here is the output from my tool on linux running against TradeMyBit. First value is profit reported from them, second value is my actual profit, normalised for hash rate and power consumption.

Code:

nist5       0.00022 0.00589
x13         0.00072 0.00532
x11         0.00051 0.00481
nscrypt     0.00269 0.00129
scrypt      0.00068 0.00068
x15         0.00007 0.00034
2014-07-15 08:54:34 Best Rate: nist5 0.00589 switch
x13         0.00102 0.00754
nist5       0.00016 0.00431
x11         0.00039 0.00372
nscrypt     0.00248 0.00119
scrypt      0.00080 0.00080
x15         0.00007 0.00034
2014-07-15 08:59:35 Best Rate: x13 0.00754 switch

I would like to work out some logic on when to switch and when to wait....any ideas?

[anon42]

Nice tool. Good work.

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.

[darius510]

Neat utility!

What's NHC's behavior when all algos are negative? As far as I can tell, it won't start a new miner if everything is neg, but if a miner is already running, it'll stay running?  I'm teetering on the edge of profitability most of the time, it'd be really useful if the user could define this behavior themselves. Rather than a yes/no, perhaps setting a lower limit? If it's just short of profitable I'd rather still let it churn away.

Does NHC take nicehash's fee into account when doing the calculation? Again, with certain nvidia cards teetering on the edge of profitability, this can be crucial.

And along the same vein...how about pulling the current BTC/USD, or any other exchange rate off of bitstamp? Not to sound like a broken record, but I'm barely breaking even here, and a wide enough fluctuation can completely change whether its worth it to mine or not.

Also, it would be really helpful if the units were defined.

Overall, the functionality is superb, and while I can handle it, the UI isn't very user friendly. I'd prefer it if everything was listed in USD rather than BTC (like multibit wallet), so I can more easily interpret what I'm seeing. Ideally everything should be configurable from the interface itself so I wouldn't have to dig into the interface to update stuff like the BTC exchange rate, but I understand that's a significant amount of UI work.

And this is totally a low priority personal request, but my setup is a GTX 770 and a GTX 750.  The 750 is there for mining and occasional physx, but I generally want to turn mining off on the 770 while I'm using the PC, and obviously when I'm gaming.  Would it be possible to set it such that individual GPUs can be toggled on off?  That might be a bit of a pain to code considering that the cards have different power profiles and hashing rates, but it would be so, so awesome. Hell, I'd code it myself if I had the source.

[StuffOfInterest]

What's NHC's behavior when all algos are negative? As far as I can tell, it won't start a new miner if everything is neg, but if a miner is already running, it'll stay running?  I'm teetering on the edge of profitability most of the time, it'd be really useful if the user could define this behavior themselves. Rather than a yes/no, perhaps setting a lower limit? If it's just short of profitable I'd rather still let it churn away.

Current behavior is to not mine on negative net earning.  Easiest way to override this would be to lower your power cost or power consumption.  You could just set the power values to zero which means you won't use power consumption in the calculation.  If you lower the power consumption value by the same amount on all algorithms it will keep the relative power in mind which calculating but give you a better chance of having at least one still profitable.

Does NHC take nicehash's fee into account when doing the calculation? Again, with certain nvidia cards teetering on the edge of profitability, this can be crucial.

And along the same vein...how about pulling the current BTC/USD, or any other exchange rate off of bitstamp? Not to sound like a broken record, but I'm barely breaking even here, and a wide enough fluctuation can completely change whether its worth it to mine or not.

Also, it would be really helpful if the units were defined.

Fee is not taken into account.  Probably should be as that could cause the net to go negative.  Something for the todo list.

I may add auto-pulling exchange rate at some point but it isn't a high priority for me.  This would add other complications.  The exchange rate and power cost are currency type neutral so you can use whatever currency you work in and still get usable numbers.  If I start monitoring specific currency exchange rates then the user will have to convert their power cost to one of those currencies to get good calculations.

Overall, the functionality is superb, and while I can handle it, the UI isn't very user friendly. I'd prefer it if everything was listed in USD rather than BTC (like multibit wallet), so I can more easily interpret what I'm seeing. Ideally everything should be configurable from the interface itself so I wouldn't have to dig into the interface to update stuff like the BTC exchange rate, but I understand that's a significant amount of UI work.

Not all of the users are in the US.  I've already had to fix one bug dealing with a country which swaps the usage of commas and periods when writing numbers.  I keep everything in BTC because this program's purpose is to mine whichever pays the best, not generate reports.

And this is totally a low priority personal request, but my setup is a GTX 770 and a GTX 750.  The 750 is there for mining and occasional physx, but I generally want to turn mining off on the 770 while I'm using the PC, and obviously when I'm gaming.  Would it be possible to set it such that individual GPUs can be toggled on off?  That might be a bit of a pain to code considering that the cards have different power profiles and hashing rates, but it would be so, so awesome. Hell, I'd code it myself if I had the source.

Run two instances of NHC in different folders.  Set each one up for a single card.  There is some real logic in doing this when using mixed cards.  Each card will have different relative hashing rate on different algorithms.  Running both on the same algorithm may not be as profitable as running the two on separate algorithms.  This will also let you stop one card from mining without affecting the other.

[StuffOfInterest]

Nice tool. Good work.

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.

[anon42]

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.

The hash rate Nicehash reports is the important one, as that is what generates the payment. Yes, it jumps around a lot, but that is what the running average is for. Also, nowadays Nicehash supports workers and reports their hashrate.

Edit: I'm running a script to test the averaging at the moment. Give me a couple of hours to get some results.

[StuffOfInterest]

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.

The hash rate Nicehash reports is the important one, as that is what generates the payment. Yes, it jumps around a lot, but that is what the running average is for. Also, nowadays Nicehash supports workers and reports their hashrate.

Edit: I'm running a script to test the averaging at the moment. Give me a couple of hours to get some results.

I'll be curious to see your results.

I haven't checked lately, but I don't think the NiceHash API has a method for getting per worker stats yet.  That will be needed in order to bring it into NHC.

[anon42]

I'll be curious to see your results.

http://jacob.j-e-b.net/nicehash.png

http://jacob.j-e-b.net/nicehash.ods

This was taken using a 1 minute counter and a 1% averaging. No compensation for ramp up/ramp down (integrated solution would have that) and no hashrate recovery.

The lower two are X11 and X13 on "nicehash control", the upper two are scrypt and sha256 on "p=xx", with the initial hashrate for scrypt misconfigured.

Looks good to me (looks better when the graph is not that compressed), more after work...

[StuffOfInterest]

I'll be curious to see your results.

http://jacob.j-e-b.net/nicehash.ods

This was taken using a 1 minute counter and a 1% averaging. No compensation for ramp up/ramp down (integrated solution would have that) and no hashrate recovery.

The lower two are X11 and X13 on "nicehash control", the upper two are scrypt and sha256 on "p=xx", with the initial hashrate for scrypt misconfigured.

Looks good to me (looks better when the graph is not that compressed), more after work...

How does this compare to the numbers coming out of the miner?  If the red line is close to what the miner reports then you really have something here.

[anon42]

How does this compare to the numbers coming out of the miner?  If the red line is close to what the miner reports then you really have something here.

Near enough to be believable. And remember that the speed Nicehash "sees" is more important than what your miner reports. Nicehash does the payouts, not your miner

Update with data up till now: http://jacob.j-e-b.net/nicehash2.ods

It also contains the raw readings (columns are in pairs, algo0-raw, algo0-calc, algo1-...), so you can try out other formulas. Mine was just "speed = (speed*99+new_value)/100" with a check of "new_value > 0".

Note: Real implementation would need to make sure to not take readings in the 5-minute ramping up phase. You can see the negative effects in my graphs above after each blue spike. It also should use some recover logic, e.g. what I outlined above, so a bad phase does not disable an algo forever.