Pages:
Author

Topic: [ANN] NiceHash Control 1.1.1 - Auto profit switching control for NiceHash servic - page 2. (Read 30028 times)

sr. member
Activity: 401
Merit: 250
Uh oh, now what about WestHash?
Yea, I'm not happy about that.

I may have to put a base URL parameter in to allow users to select which site to go to.  Haven't decided yet.  If this turns into too much of a debacle I may start looking at other options for mining instead.
newbie
Activity: 30
Merit: 0
Uh oh, now what about WestHash?
member
Activity: 130
Merit: 10
Meanwhile take a look at: http://algox.eu/stats.html, most of the time the data is accurate, but unfortunately it cannot capture nicehash really well,...but those prices we know already Wink
member
Activity: 130
Merit: 10
sr. member
Activity: 401
Merit: 250
Hey any new progress on NHC? It would be really nice if you could implement at least a partial TMB support, even thought you don't have a functioning API yet Smiley The NC prices are really low atm, so a second switching option would be awesome.

Unfortunately, too much with the home life right now.  At least it looks like TMB did extend their API for real pay rates rather than just normalized values.  That will make it easier.
member
Activity: 130
Merit: 10
Hey any new progress on NHC? It would be really nice if you could implement at least a partial TMB support, even thought you don't have a functioning API yet Smiley The NC prices are really low atm, so a second switching option would be awesome.
sr. member
Activity: 401
Merit: 250
It appears to be an issue with nicehash control -- I have this issue with any CCminer 1.1, 1.2, and the latest NVMiner build.

Behavior only present on auto-switching.

The behavior is present across multiple rigs (780 rigs, 750ti rigs). Running the miner with a built in pause command does not change the behavior either.

Again, it still generates shares, but they are either not submitted to my deposit address, or it is running in benchmark mode.


It's typical fast-ccminer-switching behavior. There might be a need of a certain pause before it launches a new miner. Something like 10-30 seconds would be fine (and would make  a nice .conf setting).
I've noticed it before while playing with different algo's ^^" Running 10-20 yay's and quickly switching to another algo was a bad idea Cheesy

I'll add that as a config option, eventually.  Until then, my earlier suggestion of having a "sleep" command in a batch file before launching the miner is the best workaround.
hero member
Activity: 644
Merit: 500
It appears to be an issue with nicehash control -- I have this issue with any CCminer 1.1, 1.2, and the latest NVMiner build.

Behavior only present on auto-switching.

The behavior is present across multiple rigs (780 rigs, 750ti rigs). Running the miner with a built in pause command does not change the behavior either.

Again, it still generates shares, but they are either not submitted to my deposit address, or it is running in benchmark mode.


It's typical fast-ccminer-switching behavior. There might be a need of a certain pause before it launches a new miner. Something like 10-30 seconds would be fine (and would make  a nice .conf setting).
I've noticed it before while playing with different algo's ^^" Running 10-20 yay's and quickly switching to another algo was a bad idea Cheesy
newbie
Activity: 9
Merit: 0
It appears to be an issue with nicehash control -- I have this issue with any CCminer 1.1, 1.2, and the latest NVMiner build.

Behavior only present on auto-switching.

The behavior is present across multiple rigs (780 rigs, 750ti rigs). Running the miner with a built in pause command does not change the behavior either.

Again, it still generates shares, but they are either not submitted to my deposit address, or it is running in benchmark mode.

I tried to diagnose a bit what might be happening here, but with no luck. NiceHash Control only starts a process and later kills it. There seem to be no other IPC, no OpenCl/Gl calls, or such things.

The only thing I can think of is that maybe ccminer leaves the GPU in a bad state when it is being killed. Do you start ccminer directly from NiceHash Control or do you use a batch file? How current are your GPU's drivers? Have you tried NiceHash Control 1.1? (That version uses a different way to kill the miner.)

Also, have a look at ccminer's window. Any messages there? (Both at startup and while it is running.) Does it go "yay!!!"? Does it say "benchmark mode"?

If that doesn't help, please post your nicehashcontrol.conf and batch files (remove your passwords!!! and user names).
newbie
Activity: 5
Merit: 0
It appears to be an issue with nicehash control -- I have this issue with any CCminer 1.1, 1.2, and the latest NVMiner build.

Behavior only present on auto-switching.

The behavior is present across multiple rigs (780 rigs, 750ti rigs). Running the miner with a built in pause command does not change the behavior either.

Again, it still generates shares, but they are either not submitted to my deposit address, or it is running in benchmark mode.


sr. member
Activity: 401
Merit: 250
For some reason when I use this, if I switch from any algo, to another, and back to original algo (doesn't matter which), the original algorithm will not mine. It winds up in benchmark mode for some reason (generates shares, but none are submitted). This is fixed if it closes the window and restarts (maxtime reached).

Anyone else experience this issue? Don't like missing 30 minutes of hashing everytime I switch an algo

Which miner are you using?  I wonder if there could be an issue with the new miner instance re-initializing the video card before the previous instance has fully spun down.

Please see if you can recreate this behavior using the start buttons on the individual algorithms.  If you hit the start button for an algorithm and another one is already running it will do a stop on that existing one and start the new one immediately, just like when an algorithm switch occurs.  If you can trigger the behavior, then try doing a stop, wait for a second, and then hit the start button for another algorithm.  If the first test triggers the problem and the second doesn't then it is likely a re-initialization issue.

A workaround I can suggest for this is to find one of the sleep utilities on the Internet.  Do a search on "sleep.exe" and you'll find a ton of them.  Run your miner from a batch file and put a sleep in front of starting the miner for however long is required based on your tests above.  This will let the card calm down before the new miner hits it again.

Hope this helps.
newbie
Activity: 5
Merit: 0
For some reason when I use this, if I switch from any algo, to another, and back to original algo (doesn't matter which), the original algorithm will not mine. It winds up in benchmark mode for some reason (generates shares, but none are submitted). This is fixed if it closes the window and restarts (maxtime reached).

Anyone else experience this issue? Don't like missing 30 minutes of hashing everytime I switch an algo
full member
Activity: 140
Merit: 100
Awesome software...  Wink

Does the hash and power values configured for each algo at CONF file affect the algo switching, or it uses some other info?

The values affecting price switching in terms of worth are power, hash and the price. Also affecting switching are min, max and switch time.
Thank you...

So far its doing perfectly.

 Wink
full member
Activity: 146
Merit: 100
Awesome software...  Wink

Does the hash and power values configured for each algo at CONF file affect the algo switching, or it uses some other info?

The values affecting price switching in terms of worth are power, hash and the price. Also affecting switching are min, max and switch time.
full member
Activity: 140
Merit: 100
Awesome software...  Wink

Does the hash and power values configured for each algo at CONF file affect the algo switching, or it uses some other info?
newbie
Activity: 9
Merit: 0
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.


sr. member
Activity: 401
Merit: 250
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.
newbie
Activity: 9
Merit: 0
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...
sr. member
Activity: 401
Merit: 250
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.
newbie
Activity: 9
Merit: 0
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.
Pages:
Jump to: