Topic: MultiMiner: Any Miner, Any Where, on Any Device (Free, Open Source, Cross Platform) - page 69. (Read 827336 times)

Oh also, in order to find other devices on the network (other multiminer instances) does "Permitted IPs"  in advanced Miner Settings need to include the Primary/Central MultiMiner box IP?

Lastly, do I need to add any Arguments for Scrypt in that same menu (if I want to run the miners at 850 overclock)?

Thanks!

Downgrading from 4.5.1 to 4.5 seems to have resolved my crashing issue.  Prior to the downgrade I actually had both MuM and BFG crash on me.  Thanks.

There's no feature for switching all machines in MobileMiner though it's a good suggestion. I don't personally have any scaling suggestions but others here may have more information. I run a bunch of different types of rigs and hardware rather than a lot of the same thing.

Cool!

Option 2 sounds like it will work then.

In that case (since your latest release to MobileMiner) can you do the same with MobileMiner "assign to all rigs on your network"?

Do you see any other scaling issues or any tips on setting this up correctly?

Thanks!

I don't think this will work without additional development. Currently (to my knowledge) the Stratum Proxy in BFGMiner doesn't work with Scrypt mining.


If you go this route you do not need to use MultiMiner as a Stratum Proxy. You can enable MultiMiner Remoting (under Perks) and then you will see every other MultiMiner rig from any other rig. You can then control them from anywhere and you can switch pools on all of them from any single rig.

MultiMiner Remoting features / screens:

So what is your recommended setup if I have 1000 gridseed 5-chip units?

I am thinking,

Option 1:

10 windows or linux boxes with 100 gridseed units (per box) running just BFGminer 4.0 that connect to multiminer (stratum proxy for switching coin pools) on the LAN but then I loose some MultiMiner features like rebooting failed devices/alerts right?

Option 2:

10 windows boxes running MultiMiner with 100 gridseed units (per box) running MultiMiner (with bfgminer 4.0) that connect through a MultiMiner proxy box (for switching coin pools) on the LAN so I will have the alerts and be able to switch all boxes to different pools at once. BUT with this option, the there may be inefficiencies in how MultiMiner/MobileMiner is setup.

Objectives:
Remotely Monitor all gridseed units
Alerts/Notifications (for bad units)
Ability to change coin pool from one central location

Also, if option 2 is best, I would plan to setup redundant MultiMiner boxes for failover purposes.

Do you see inefficiencies in doing this that affect hashrate and or anything else you can think of?

Thanks!

Logged in remotely how? Are you using RDP or VNC? GPU mining does not work via RDP and you will end up with very odd results as the full AMD driver will not load.

Edit: Try posting a screenshot or a video of the problem. That may help. The Start button is disabled if you don't have a valid configuration - e.g. no devices or your devices have no selected coin configuration or your configurations have no pools etc.

Hi nwoolls,

My Multiminer does not start. It takes so many restarts and reboots to finally get it going. The program opens but it wont start mining, any solutions? I see STOP and RESTART but Start is greyed out. Well, thats the button I need because it WONT START lol. IT reminds me of FORCE START on utorrent.

This usually happens after the  "The AMD driver has crashed and successfully recovered" note. When I logged in remotely there was a Windows 8.1 message that the program has recovered from a crash and if I want to report it to microsoft. CGMiner runs fine by the way.

I actually forgot how I got it going last time. Maybe shut down completely then reboot. Which is something I cant doo right now as I am not near the RIG Im connecting remotely. I cant believe there is a difference between cold boot and reboot. Why?

Thanks!!

P.S. In my cgminer days, I had a command in the .,bat file to delete all the BIN files before cgminer starts. This eliminated lots and lots of my issues that would carry over to the next time I would run CGMINER, ,for example CGMINER wouldnt recognize a card or call it sick, with BIN deleted it would start full force from scratch without remembering what happened before. I think your program (or bfgminer) needs something like that to "forget" all the issues from the previous run and start from scratch.

So frustrating to find out the RIG has done NOTHING in the past 4 hours and I cant even reboot it in the next 8 hours.

MobileMiner query:

I'm trying to set up BFGMobileAdapter on my Raspberry Pi (which I believe runs Python 3).

I added the --api-listen to the command line of one of my BFGMiner instances.

I run the BFGMobileAdapter python script, and it runs, it says it's getting data, and then says "KeyError: u'MHS 5s'.

Any idea what that is?

I haven't tried that many but you can give it a shot. I've had others report they are able to run 10 & 20 of them at a time. You can use the latest release of MultiMiner. Check this post for instructions:

https://bitcointalksearch.org/topic/m.5617775

Nwools, how well do you think MM and BFG 4.0 will respond with controlling 20 Gridseeds in LTC only.  Would love to not have to have 20 prompts open on my box I host them on LOL!

The source code is definitely setup for it so that's not a problem. And there are examples and some documentation. For me I'd rather invest the time adding support for new algorithms and devices in BFGMiner rather than writing more layers over backend miners (which require maintenance as each of those miners change). It's just more interesting to me.

It's also a "creep" thing. Similar to why I've never included a default pool. As soon as you do one, then you have to do another, and another etc. CGMiner, SGMiner, VertMiner, CudaMiner, etc. etc.

I appreciate the understanding and - again - welcome anyone to work on an abstraction layer for these different miners.

Edit: I will stress that one of the reasons that I moved to only a single backend miner was a conscious decision to try to keep MultiMiner focused and streamlined and to support the largest set of features in the backend miner and have everything just work. If it were to go back to supporting multiple miners that would need to still be a focus.

No prob, I'm sure people will contribute with code, the suite seems worth the effort.

You can try trial-and-error with the command line to try to figure out what combination is causing BFGMiner not to list devices. Your original outputs showed a total at the bottom and listed OpenCL devices. That needs to happen. Try removing command line arguments & devices until it succeeds, then add them back until you narrow down the one item causing it. Then report it in the BFGMiner thread here or in the GitHub issues here.

I'm sorry Nate, but... what do you advise me to do?
Throw in the towel?
If I've well understood, also the latest 2.8 release can't solve my problem.
I was dying to run MultiMiner on my Mac...
 

Anyone is welcome to contribute code. In the meantime I will be spending what time I do have improving MultiMiner, BFGMiner, and MobileMiner. I'm not personally interested in trying to support a wide range of back-end miners that have varying command lines and APIs. I'd rather improve BFGMiner, which I personally think is a more worth-while way to spend my time.

Sounds really good...hope you get some time to support sgminer/cgminer/yacminer one day.

MultiMiner 2.8 is now officially available with the following features and improvements:

• Official support for 1-chip and 5-chip GridSeed ASICs (requires BFGMiner 4.0)
• Added support for the MobileMiner Pools API, allowing switching coins from phones and browsers
• Added the option to save coin configurations to all rigs via MultiMiner Remoting
• Notifications are now displayed when Auto-Mining switches to new coins
• When minimized to the system tray, an interactive balloon tip is displayed for in-app notifications
• Coins that fall below strategy configurations are no longer suggested for mining
• Coin difficulty is read directly from the network once mining begins
• Worker temperatures are shown for Network Devices and the Stratum Proxy
• Added the option to Copy / Clone an existing configuration in the Configure Coins dialog
• Customized names for machines and devices are now pushed to MobileMiner
• Improved overall performance

So... I AM DOOMED! 

Interesting! That explains why it's not working 

For some reason BFGMiner on your system isn't getting to the part where it outputs all the devices.