Might be quite a simple question. I have 2 rigs that are run by AM from another machine, i.e. each rig runs an AM remote service. When remote service starts a mining process (ccminer in most cases), its console is not shown on screen, and I can't see the console in AM miner - it's just empty. Is is possible to have console starting on the remote machines to see what's going on with the currently running mining process?

Being polite to people who try to help you might give you better results. Jus sayin'.

Now, onto your question - the AM is not particularly clear on what you need to put into your managed software "User defined command line argument". What it should be is the line that starts with the algorithm. So if you want to change intensity for your phi algo, your command line arguments should read (no quotes), "phi --intensity 25" or "phi -i 25". I saw a few people on this thread (and myself at the first attempt) to putting just "-i 25" to the user defined command line argument and wondering why ccminer shuts down right after the start. If you try to diagnose it, you'll see that it throws an error "unknown algorithm" and the command line after -a parameter is missing "phi".

One thing I can think of is delaying AM service start - you can achieve it in a variety of ways with the simplest being setting it start option to Autostart (Delayed). I use AlwaysUp to keep several pieces of software running as services and starting up at the machine boot and there you can have better control of what starts when. But apparently none of these solutions have anything to do with AM - it'll try to start a miner the moment it detects the connection to AM service, so I guess the trick is to delay the availability of the latter.

Right, but what I'm saying, initially I thought of adding same waiting (I was surprised we were limited to 99 sec wait ) but it didn't work for me for some reason - it just kept calling the url almost continuously. From the AM examples I understand that same "wait" can be achieved with using timer and setting "match all conditions", like "detect offline + timer every 5 minutes". This has its downside so that in the worst case scenario you'll detect your downtime 5 minutes after it occurred, BUT on the positive side it will not occur again for another 5 minutes, effectively doing same thing as those wait commands.

Nice and detailed write up, thanks for that.

I did something similar with SmartThings and smartplugs. Basically when AM notices any "service degradation", i.e. service is offline, device crapped out (i.e. # of devices less than expected) or "device is sick" (have no clue what that means - never saw that happened to a GPU) - then it triggers an action in webCore, which starts a 1 minute countdown timer. I get a notification on the phone with options to power cycle a rig right away or cancel. If no response is received within a minute then the rig is power cycled (if you are doing that to a GPU rig you need to ensure that "recover after power loss is turned on in BIOS).

One thing that didn't work for me is waits on the AM side - it kept sending reboot requests, so I basically created a latching switch, that allows a single reboot within a 5 minute interval - that allows plenty time for a rig to recover.

In all though, it's nice to see that we are thinking generally in the same direction

Right, but if I'm away for some time I also want it to keep mining until I'm able to troubleshoot, hence the question. Good point about changing pools rule, I need to look into that further.

after creating an account you need to create workers on the mph site... those name you'll be using when configuring your individual rigs in AM

for mph you need to set your workers names in the account settings (on the mph site) and they you can customize worker name per rig in AM.

From my experience you need to be careful when selecting pools for this. AHashpool is most reliable in terms of not experiencing / showing crazy spikes, while zpool and MHP are the worst.

@puwaha, @patrike

question for you if you don't mind. I understand your argument for using 24hr averages (and preferably even longer) vs instant and having running switching no more often than once an hour or so. I'm still to see the results - I used to run switching every 1-5 minutes with a high threshold for switching, like 30-40% (call it 1/1/30). I need to run it for the whole day or 2 to make a conclusion. But here's a problem that surfaced right away when using 24hr/1hr pattern (i'll call it 24/1/10) - bad pools. So if I run 1/1/30 and the pool is bad, which can be manifested in multiple ways, for instance AM keeps restarting a miner saying that the process is not running (though accepted # keeps ticking) or no accepted blocks are coming in, then the pool will potentially quickly drop off the top of the profitability table and AM will happily switch to (hopefully) a non-corrupted pool. Now if the same problem arises during my 24/1/10 configuration, I'm potentially screwed for hours - the best AM miner can do here (I wish it could be more intelligent dealing with multiple restarts, except just stop trying after X times and stopping the miner in the process) is to keep restarting the miner, which does no good, since it keeps going back to the same corrupted pool. Have you run into something like this before (btw, it seems that lots of pools are having problems in the last couple days)? How would you deal with it?

PS: I find it quite useful to monitor the # of accepted blocks in the last 3-5 minutes and if that number stalls force profit switching and restarting the rig. HOWEVER, and that might be another question, it seems that AM has a "miner not running, restarting" routine that's run outside of the rules framework and I can't figure out how to intercept it and, potentially, force it to run a profit switching before restarting the miner - have you ever dealt with that one?

Thanks!