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

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: ghotiphry on August 01, 2014, 09:40:45 AM

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.

ghotiphry

newbie

Activity: 30

Merit: 0

Uh oh, now what about WestHash?

ltc_bilic

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

ltc_bilic

member

Activity: 130

Merit: 10

You know family first Wink

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: ltc_bilic on July 28, 2014, 02:19:28 PM

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

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.

ltc_bilic

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

The NC prices are really low atm, so a second switching option would be awesome.

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: Bombadil on July 23, 2014, 02:41:37 PM

Quote from: maelstrom987 on July 21, 2014, 06:43:48 AM

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.

Bombadil

hero member

Activity: 644

Merit: 500

Quote from: maelstrom987 on July 21, 2014, 06:43:48 AM

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

anon42

newbie

Activity: 9

Merit: 0

Quote from: maelstrom987 on July 21, 2014, 06:43:48 AM

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

maelstrom987

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.

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: maelstrom987 on July 20, 2014, 05:23:05 PM

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.

maelstrom987

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

RavenXBR

full member

Activity: 140

Merit: 100

Quote from: DemosMirak on July 19, 2014, 11:45:22 AM

Quote from: RavenXBR on July 19, 2014, 11:03:23 AM

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

DemosMirak

full member

Activity: 146

Merit: 100

Quote from: RavenXBR on July 19, 2014, 11:03:23 AM

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.

RavenXBR

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?

anon42

newbie

Activity: 9

Merit: 0

Quote from: StuffOfInterest on July 18, 2014, 06:51:51 AM

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.

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: anon42 on July 18, 2014, 02:28:21 AM

Quote from: StuffOfInterest on July 17, 2014, 04:32:40 PM

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

newbie

Activity: 9

Merit: 0

Quote from: StuffOfInterest on July 17, 2014, 04:32:40 PM

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

Activity: 401

Merit: 250

Quote from: anon42 on July 17, 2014, 03:31:19 PM

Quote from: StuffOfInterest on July 17, 2014, 09:15:00 AM

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

newbie

Activity: 9

Merit: 0

Quote from: StuffOfInterest on July 17, 2014, 09:15:00 AM

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.

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