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

I cleaned up the order once but it probably got out of order again when I added the newer algorithms.  Thanks for bringing it up.

I'd be very interested in a monitoring app that is networked! Please do

Also, yeah the bouncing back and forth between algos seems to happen too frequently.

Thanks for your continued work on this, love the utility! Just a minor note regarding UI conventions, the tabindex is a bit out of order on the buttons. Obviously, nothing that's a major issue just figured you'd want to know

Hi my guys, I'm having problems. Yesterday I connected a new card (one xfx 280x, I have installed 2xGigabyte 280x), at the beginning everything was working fine, but when the change to x11 to x15 appears this:



I use trixx with this configuration. gpu 1060, memory 1500, v1.275 in the xfx and the two gigabyte gpu 1060, memory 1500, v1.094. The temperatures is normal.

I have not changed anything in the NiceHash Control.


It is a error of my cards or the server of nicehash?

thanks

Didn't noticed that you've answered on my question. Yes I'm running on same subnet.

It happened only once, and I couldn't see the miner's situation, because it was minimized but there was no ccminer process running, so had to launch it manually.

It appears that nicehash implemented the workers names, like you've requested

"Providers: You can name your rigs. Append . (dot) and up to seven alphanumeric characters to Bitcoin address."

I've been looking around for a managed code library which can access the NVIDIA API.  I think I may have found one but I haven't had time to play with it yet.  If I could use that to see if the GPU is under load that would be one way to see that the miner is sitting idle.

Something like that can't work?
Try 10x, then move to next line and if pool goes down while mining, he try the next line, and loop.

Bad thing is we can't go back to main pool if he's coming back online, only way is to kill process and restart like every hours

But will need to set a failover for each algo when mining with nvidia

:loop
ccminer -r 10 -R 30 --algo=x11 -o stratum+tcp://stratum.nicehash.com:3336 -u btc-add -p d=0.04
ccminer -r 10 -R 30 --algo=x11 -o stratum+tcp://yourfailover -u user.worker -p workerpass
goto loop

Hope a day cudaminer/ccminer will buil failover inside miner like cgminer/sgminer have

Perhaps it would be worth investigating how to check the GPU load. If you have that info then "backup pools" are piece of cake. Some knowledge of CUDA or better DirectX are needed. If used with DirectX it can be used on any sort of miner.

Definitely interesting ideas.  Item 2 is fairly easy to implement but item 1 could be more difficult as I don't have a way of detecting if the pool is down.  If the miner is configured to exit if the pool is not available then how do I determine if it failed because of the pool being down or because of a problem with the miner?  Also, what condition do we use to switch back. 

Currently, NHC doesn't talk to the stratum at all, just launches miners and makes sure they keep running.

Nice tool

2 things you can try to add:

1) Possibility to set a failover pool not related to nicehash in case nicehash is down, or point 2) not meet
2) Set our minimum price at wich one we want to mine to nicehash to each algo with p=x.xx and if all price lower than our, mine to the failover

You can use it with NHC, but it won't do you any good because it relies on new algorithm that is not supported by NiceHash yet.

Is possible mix the NiceHash Control with this Mod by aznboy84? excellent for some extra hashrate. Thank

Unfortunately, without Visual Studio connected to the app when this occurs it will be hard to track.

Each minute, after updating prices, I check that the process has not gone into a "HasExited" state.   If it has, then I restart the miner.  When your miner crashed, did it exit out or was it sitting at some sort of error display?  If the miner window went away completely then it should have restarted on the next minute.

Any info on the state things were in will be helpful.

One workaround I can think of adding is a max time to mine.  Set a time of one or two hours after which the miner will be killed and restarted, same as if there was an algo switch.  If the miner is hung then this should get it back in a running state.  When I get the time based event code in I'll make that one more feature to include.

I really wish NiceHash would implement a worker ID (appended on the address) so you could see what each miner is doing from the NiceHash website.  I've had a similar problem (before using NHC) on my second machine which I don't look at very often.  Unfortunately, its hash rate is low enough to be lost in the noise of the main machine.

Question.  Are all of your machines on the same network?  I'm thinking about trying to create a monitor app that could get redirected output from all mining rigs on one network.  Will probably use multicast for simplicity, which means it would not cross a router.  Just curious if there is any demand for something like this.

PS: Dang flicker!  I really need to get the minimum time hooks in. I'm bouncing between X11 and X13 again tonight.  Spent one whole minute on X13 before switching back.

There appears to be a bug: it happened that the NHC was "working" visually as it should but the miner died for some reason, and NHC continued "working",... i've caught it only once because I've noticed sudden hash drop and went to manually inspect every miner

Any debug options so I can help to hunt it down?

Fun fact.

Just closing in on one month of mining full time on NiceHash.  I've been using 2 x GTX 750 Ti with part time help from a GTX 650 Ti BOOST in another computer.  For three weeks I've been auto-switching using NiceHash Control.  In that time I've made about 0.08BTC or $50 equivalent.  Not a lot, but if the rates hold up at all then the cards should at least pay for themselves eventually.

I don't think cudaminer nor ccminer have backup functionality at this moment, someone correct me if I'm wrong. But I've seen this: https://github.com/KBomba/failover-ccminer-bat but didn't have the time to test it out.

The time buffer is definitely moving up on my priority list as I was getting hit by the same flickering between x11 and x13 yesterday.  A couple of days ago I actually had it go between x11, x13, x15, and Nist5 all in the span of a couple of hours.

My plan is to implement a pre-buffer and a post-buffer for the switching.  The pre-buffer will prevent switching for an amount of time in case the algorithm switches and switches back over just a minute or two.  The post-buffer will act as a minimum amount of time to mine so that once a switch does occur it won't switch again for that amount of time.  If the kid goes to bed early enough the next couple of nights I might have time to work on it during my 9:00 PM to 10:30 PM "me time" window.

Regarding showing a section of the output in the control program, I've thought about that.  CUDA Manager does exactly that.  This wouldn't be too difficult with cudaMiner and ccminer as they use basic output which can be captured and shown elsewhere.  The problem comes in with programs like sgminer or the ccminer-splitscreen branch which has a more interactive display.  I have no idea how bad this would interact with a straight dump.


Nothing I can do there.  I could be wrong but cudaMiner may support backup pools already.  I know ccminer doesn't but from what I've been reading on the appropriate thread there are a couple of people interested in implementing it.

I've thought about trying to do something from the NiceHash control program to handle switching but there are so many issues it just hasn't been worth looking too deep into so far.  Fortunately, the down time for NiceHash has been infrequent enough that it hasn't been a major issue for me.

I actually started using the option for myself as I run the miner on my main PC and putting it in the tool tray helps to unclutter the task bar.  Yes, it could be used for more nefarious reasons but hopefully people will use their own discretion.  Good way to get kicked off of a network like the fool who used a university supercomputer to mine Bitcoins.

It's an option you don't need to use it  in my case it's essential before I was running a GPU farm on a campus now I've moved all the cards to our office (yes I'm the owner - so it's not illegal anymore )

Today I was testing it, but unfortunately there was not a lot of switching done today, but when I was running it yesterday I remember there were quite a lot of switching happening for 1/2 min back and forth,...so I think you should consider implementing a "5 min buffer", where it would keep track of the new price and it won't switch immediately as of now, but after 5 min if the new price is still better then current,...this would avoid the constant switching if you're specs are very similar for different algos like x11 and x13. Yes when you minimize it you cannot bring up the miner window and you can only manually stop and start in order to see what's going on well it's not an elegant solution. IMO the next step would be to include the miner window on Control Form right next to Activity tab, and print out the last few lines of what's happening, so in this case you would avoid the previous issue and have an elegant overview of what's happening with the miner. Some people would like to see the gpu temp fan speed and all the neat stuff that cuda manager has, but I don't think it's necessary because it's meant to be used with newer generation nvidia cards and those suckers are running cool and quiet 

More important feature for "todo list" would be to the lack of backup pools in ccminer/cudaminer so to detect if there's a problem with hashing and miner starts running on a backup pool. When situation goes to normal tries to switch back to the most profitable nicehash algo.

Will continue to test and report back.

I'm not sure the hidden mining option is a smart move as I can only see negative reasons to use it...