Bitcoin Forum
January 24, 2018, 12:18:46 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 [6] 7 8 »  All
  Print  
Author Topic: [ANN] NiceHash Control 1.1.1 - Auto profit switching control for NiceHash servic  (Read 29399 times)
thquan819
Member
**
Offline Offline

Activity: 70


View Profile
July 14, 2014, 09:16:27 AM
 #101

Please add 2FA Security
1516753126
Hero Member
*
Offline Offline

Posts: 1516753126

View Profile Personal Message (Offline)

Ignore
1516753126
Reply with quote  #2

1516753126
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1516753126
Hero Member
*
Offline Offline

Posts: 1516753126

View Profile Personal Message (Offline)

Ignore
1516753126
Reply with quote  #2

1516753126
Report to moderator
1516753126
Hero Member
*
Offline Offline

Posts: 1516753126

View Profile Personal Message (Offline)

Ignore
1516753126
Reply with quote  #2

1516753126
Report to moderator
1516753126
Hero Member
*
Offline Offline

Posts: 1516753126

View Profile Personal Message (Offline)

Ignore
1516753126
Reply with quote  #2

1516753126
Report to moderator
Zels
Full Member
***
Offline Offline

Activity: 198



View Profile WWW
July 14, 2014, 09:30:43 AM
 #102

Please add 2FA Security

 Shocked Huh Huh Huh

HBN: ErmqaiunrcguMEhpDP5uqEQhRKmn3oViWv
StuffOfInterest
Sr. Member
****
Offline Offline

Activity: 380


View Profile
July 14, 2014, 09:56:44 AM
 #103

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?

Miner Control to get auto algorithm switching for multiple mining services. (please donate if you like)
Could Proof of Blockchain (PoBC) help secure a coin and avoid runaway ASIC mining?
ltc_bilic
Member
**
Offline Offline

Activity: 107


View Profile
July 14, 2014, 11:27:32 AM
 #104

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  Huh need to add this exception if all the prices are 0 Wink
StuffOfInterest
Sr. Member
****
Offline Offline

Activity: 380


View Profile
July 14, 2014, 11:43:45 AM
 #105

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  Huh need to add this exception if all the prices are 0 Wink

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.

Miner Control to get auto algorithm switching for multiple mining services. (please donate if you like)
Could Proof of Blockchain (PoBC) help secure a coin and avoid runaway ASIC mining?
ltc_bilic
Member
**
Offline Offline

Activity: 107


View Profile
July 14, 2014, 12:48:45 PM
 #106

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.

 Grin
DemosMirak
Full Member
***
Offline Offline

Activity: 146


View Profile
July 14, 2014, 05:18:31 PM
 #107

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

BTC: 13enECLM3M3gjQDoBKouXuYFG4zXaDdDPx
LTC: LRTbQNQcRjZV51PivQdhK7zpMtJYPouqR9
StuffOfInterest
Sr. Member
****
Offline Offline

Activity: 380


View Profile
July 14, 2014, 07:14:57 PM
 #108

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.

Miner Control to get auto algorithm switching for multiple mining services. (please donate if you like)
Could Proof of Blockchain (PoBC) help secure a coin and avoid runaway ASIC mining?
DemosMirak
Full Member
***
Offline Offline

Activity: 146


View Profile
July 14, 2014, 07:37:46 PM
 #109

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.

BTC: 13enECLM3M3gjQDoBKouXuYFG4zXaDdDPx
LTC: LRTbQNQcRjZV51PivQdhK7zpMtJYPouqR9
StuffOfInterest
Sr. Member
****
Offline Offline

Activity: 380


View Profile
July 14, 2014, 07:53:36 PM
 #110

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.

Miner Control to get auto algorithm switching for multiple mining services. (please donate if you like)
Could Proof of Blockchain (PoBC) help secure a coin and avoid runaway ASIC mining?
miner256
Newbie
*
Offline Offline

Activity: 23


View Profile
July 15, 2014, 08:10:05 AM
 #111

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
Newbie
*
Offline Offline

Activity: 9


View Profile
July 16, 2014, 10:04:53 PM
 #112

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
Newbie
*
Offline Offline

Activity: 5


View Profile
July 17, 2014, 03:54:20 AM
 #113

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. Smiley

StuffOfInterest
Sr. Member
****
Offline Offline

Activity: 380


View Profile
July 17, 2014, 01:10:53 PM
 #114

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.

Quote
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.

Quote
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.

Quote
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. Smiley

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.

Miner Control to get auto algorithm switching for multiple mining services. (please donate if you like)
Could Proof of Blockchain (PoBC) help secure a coin and avoid runaway ASIC mining?
StuffOfInterest
Sr. Member
****
Offline Offline

Activity: 380


View Profile
July 17, 2014, 01:15:00 PM
 #115

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.

Miner Control to get auto algorithm switching for multiple mining services. (please donate if you like)
Could Proof of Blockchain (PoBC) help secure a coin and avoid runaway ASIC mining?
anon42
Newbie
*
Offline Offline

Activity: 9


View Profile
July 17, 2014, 07:31:19 PM
 #116

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
Sr. Member
****
Offline Offline

Activity: 380


View Profile
July 17, 2014, 08:32:40 PM
 #117

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.

Miner Control to get auto algorithm switching for multiple mining services. (please donate if you like)
Could Proof of Blockchain (PoBC) help secure a coin and avoid runaway ASIC mining?
anon42
Newbie
*
Offline Offline

Activity: 9


View Profile
July 18, 2014, 06:28:21 AM
 #118

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
Sr. Member
****
Offline Offline

Activity: 380


View Profile
July 18, 2014, 10:51:51 AM
 #119

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.

Miner Control to get auto algorithm switching for multiple mining services. (please donate if you like)
Could Proof of Blockchain (PoBC) help secure a coin and avoid runaway ASIC mining?
anon42
Newbie
*
Offline Offline

Activity: 9


View Profile
July 18, 2014, 06:42:13 PM
 #120

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 Wink

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.


Pages: « 1 2 3 4 5 [6] 7 8 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!