MultiMiner: Any Miner, Any Where, on Any Device (Free, Open Source, Cross Platform)

[mstrongbow]

edit... Version 3.0.1 crashes and cannot detect GPU (intel HD 4000 )... seriously, it crashes.

As others have said I doubt Intel GPUs are supported. That said, if you are seeing a MultiMiner crash, please post the details using copy & paste. Thanks 

v2.8.10 works perfectly... but not 3.0.1. I used intel hd 4000 just for YT, im not mining long term.
Will post error later.

Word. Yeah I have never been able to get any of my Intel powered units to fire up and hash for anything!

[bensam123]

A update on some issues I've run into.

X11 still seems to have issues with connecting to pools in MM. This is the same problem I listed earlier. Eventually MM will end back up on the right pools, but to start with it'll go to my backup pools first. Where as with SGHMINER it goes right to the proper pool immediately (I dropped in the same exact version I use with the bat file). There has to be something with MM and the way it deals with down pools.

Profitability switching was fucked up for a bit. It started switching itself on randomly even after I turned it off. I seem to have completely disabled it, but it was mining random coins for a fair bit of time (like Doge, which I no longer mine anymore). One machine I thought I fixed went and turned it back on again.

X11 seems to produce worse hash then running the miners in standalone. This is with SGHMINER. Running standalone they'll produce about 15% more hash then using MM and the same exact version of SGHMINER. This is when they're on the same pools and using the same settings.


There seems to be a overall problem when switching between algorithms and settings (TC does this a lot). This probably doesn't relate directly to MM, but sometimes unless you do a clean restart switching between a different algorithm (like x11 and scryptn for example) will produce a inferior hash rate until you restart. Sometimes it will cause GPUs to hang as well (which can be fixed sometimes by simply restarting the miner or if need be restarting the system).

This like I said probably doesn't have anything to do with MM, but if there was a way to completely flush the drivers before reinitializing a different algo, it'd probably help fix this. As of right now I don't know how to do this without restarting.

I'm using APP SDK 2.9 and AMD 13.12 drivers.

[nwoolls]

A update on some issues I've run into.

X11 still seems to have issues with connecting to pools in MM. This is the same problem I listed earlier. Eventually MM will end back up on the right pools, but to start with it'll go to my backup pools first. Where as with SGHMINER it goes right to the proper pool immediately (I dropped in the same exact version I use with the bat file). There has to be something with MM and the way it deals with down pools.

In a nutshell, MultiMiner is launching the executable found on the Process Log screen (available from right-click) with the arguments found there too. There's nothing beyond that MultiMiner is doing. That needs to be the starting point for diagnosing the differences you are seeing.

FWIW I see this problem too if I use DarkcoinSGMiner but SPHSGMiner seems to work better.

I've also seen the "all pools appear to be down" if the right algorithm arguments aren't being passed to the backend miner.

Profitability switching was fucked up for a bit. It started switching itself on randomly even after I turned it off. I seem to have completely disabled it, but it was mining random coins for a fair bit of time (like Doge, which I no longer mine anymore). One machine I thought I fixed went and turned it back on again.

This is a bug that is fixed for 3.0.2, which will be going out pretty soon. Happens when you use Quick Switch.

Edit: it's fixed in the 3.1 preview I linked previously too.

X11 seems to produce worse hash then running the miners in standalone. This is with SGHMINER. Running standalone they'll produce about 15% more hash then using MM and the same exact version of SGHMINER. This is when they're on the same pools and using the same settings.

Same response as up above - please start with the Process Log screen in MultiMiner. MultiMiner is "simply" launching the executable you see there with the arguments you see there. If you stop mining in MultiMiner, you can right-click in the Process Log and click Launch to start the miner directly.

Please use this to compare performance and see what it is specifically causing the difference you are seeing.

If you are seeing different performance simply by clicking the Launch button in MultiMiner specifically, please let me know the executable and arguments.

Thanks very much for the feedback - keep it coming!

[ManeBjorn]

Quick note.
My rigs updated to the 2.8 update and none of them are updating to 3.0.
The rig that was on 3.0 updated to 2.8 and I lost my coin configs in it.  Just odd.  I was not expecting that one to update when it was already on 3.0.
I hope it helps with anything going.

[nwoolls]

Quick note.
My rigs updated to the 2.8 update and none of them are updating to 3.0.
The rig that was on 3.0 updated to 2.8 and I lost my coin configs in it.  Just odd.  I was not expecting that one to update when it was already on 3.0.
I hope it helps with anything going.

Interesting - 3.0 should not prompt to upgrade to 2.8. I haven't seen that or heard that reported, but I will sure test it.

The rest is to be expected, unfortunately. The sordid details:

Both version 2.8.9 and 3.0 were released with code that will prevent them from notifying of "major" updates, e.g. v2 to v3. I released 2.8.10 afterward so that those on 2.8 would get major updates. Unfortunately though, folks on 2.8 (even 2.8.10) will not be prompted to update to 3.0 - for now. That is because 2.8.10 is technically the "latest" build.

Once I release 3.0.2, that will be the "latest" release and folks who are on 2.8.10 will be prompted to update. However, at that point folks on 2.8.9 won't see 2.8.10 as a viable upgrade anymore, so I don't want to pull the trigger on the update too soon. I'm watching installed version numbers and will do it when it makes sense.

It's a bit of a mess, I know, but it only affects the auto-update notification. Folks can still manually update.

And I tested the original scenario while typing this - I can't seem to see an instance of 3.0 prompting to upgrade to 2.8.

[ManeBjorn]

I had updated on one of the 2 2.8 systems and I did not think and ok'd the push to the other systems and it updated the 3.0 one as well.  Sorry I was not a bit more clear.  I was surprised but at the same time was not used to having the 3rd system yet. LOL

Quick note.
My rigs updated to the 2.8 update and none of them are updating to 3.0.
The rig that was on 3.0 updated to 2.8 and I lost my coin configs in it.  Just odd.  I was not expecting that one to update when it was already on 3.0.
I hope it helps with anything going.

Interesting - 3.0 should not prompt to upgrade to 2.8. I haven't seen that or heard that reported, but I will sure test it.

The rest is to be expected, unfortunately. The sordid details:

Both version 2.8.9 and 3.0 were released with code that will prevent them from notifying of "major" updates, e.g. v2 to v3. I released 2.8.10 afterward so that those on 2.8 would get major updates. Unfortunately though, folks on 2.8 (even 2.8.10) will not be prompted to update to 3.0 - for now. That is because 2.8.10 is technically the "latest" build.

Once I release 3.0.2, that will be the "latest" release and folks who are on 2.8.10 will be prompted to update. However, at that point folks on 2.8.9 won't see 2.8.10 as a viable upgrade anymore, so I don't want to pull the trigger on the update too soon. I'm watching version numbers and will do it when it makes sense.

It's a bit of a mess, I know, but it only affects the auto-update notification. Folks can still manually update.

And I tested the original scenario while typing this - I can't seem to see an instance of 3.0 prompting to upgrade to 2.8.

[nwoolls]

Another preview of 3.1 is available for testing:

https://www.dropbox.com/s/nmy0vlhhpje5iw0/MultiMiner-3.1.0.zip

This includes better support for recognizing multiple algorithms throughout the UI. In 3.0, "unknown" algorithms are grouped under Scrypt or SHA, for instance in the hashrate totals. With this preview those hashrates are called out specifically:

[Raptor2213]

Another preview of 3.1 is available for testing:

https://www.dropbox.com/s/nmy0vlhhpje5iw0/MultiMiner-3.1.0.zip

This includes better support for recognizing multiple algorithms throughout the UI. In 3.0, "unknown" algorithms are grouped under Scrypt or SHA, for instance in the hashrate totals. With this preview those hashrates are called out specifically:

You should run MM with two release channels.  Add two options:
□ Notify on release versions
□ Notify on beta versions

[nwoolls]

You should run MM with two release channels.  Add two options:
□ Notify on release versions
□ Notify on beta versions

It's planned  Some day!

You can specify pre-releases using semantic versioning and Github Releases can be flagged as pre-releases, so at some point I can start posting these as tagged releases on there and introduce "channels" in the UI.

[bensam123]

Please add a display option for what miner and version MM is using.

[mstrongbow]

Please add a display option for what miner and version MM is using.

Yeah..maybe just add the Version # next to MultiMiner in the title bar??

[nwoolls]

Please add a display option for what miner and version MM is using.

Click the About button in the upper-right: it shows both.

[ManeBjorn]

any idea which drivers to use for the onestring miners and yellow jacket?
I am having issues with the yellow jacket as it is a nano fury.  One sting I just want to load the correct set then use the arguments you had posted for them to work well.

[nwoolls]

any idea which drivers to use for the onestring miners and yellow jacket?
I am having issues with the yellow jacket as it is a nano fury.  One sting I just want to load the correct set then use the arguments you had posted for them to work well.

I only have a couple of IceFuries (NF1) and a NanoFury2 stick. Both of these use the standard Windows HID driver and required no driver installation.

I'm not sure on the OneString miner. If it uses the Windows CDC driver, you may need to create a custom INF for it. You can check out these existing ones for a reference:

https://www.dropbox.com/s/w06b7nj1f07lv29/Windows_ASIC_CDC_Drivers.zip

The only real differences in the INF files are the PIDs and VIDs which you can get out of the Device Manager in Windows, along with the Strings section at the bottom (which doesn't matter - just name the device).

[ManeBjorn]

Thanks Nate
I will give these a try and get the info out the device manager and see what I can do.   

any idea which drivers to use for the onestring miners and yellow jacket?
I am having issues with the yellow jacket as it is a nano fury.  One sting I just want to load the correct set then use the arguments you had posted for them to work well.

I only have a couple of IceFuries (NF1) and a NanoFury2 stick. Both of these use the standard Windows HID driver and required no driver installation.

I'm not sure on the OneString miner. If it uses the Windows CDC driver, you may need to create a custom INF for it. You can check out these existing ones for a reference:

https://www.dropbox.com/s/w06b7nj1f07lv29/Windows_ASIC_CDC_Drivers.zip

The only real differences in the INF files are the PIDs and VIDs which you can get out of the Device Manager in Windows, along with the Strings section at the bottom (which doesn't matter - just name the device).

[nwoolls]

Please add a display option for what miner and version MM is using.

Click the About button in the upper-right: it shows both.

And now with more infos 



https://www.dropbox.com/s/nmy0vlhhpje5iw0/MultiMiner-3.1.0.zip

[Oldminer]

Does anyone know what the best setting is under settings, miner, priority (assuming I want to optimize my miners)?

Is Real-time better then High for example? The list shows 'normal' at the top of the list, real-time in the middle somewhere, and 'above-normal at the bottom just below 'below-normal'  

Also, does the program need to be restarted for this setting change to take effect?

thanks

[Foss]

3.1.0 work's fine Thank you Nate!! But why BFGMINER is x32, or it's doesn't matter?

[bensam123]

Please add a display option for what miner and version MM is using.

Click the About button in the upper-right: it shows both.

I was talking about all the other miners as well. Perhaps when you're mining the coin itself. There is a lot of overlap for what miners you can use to mine coins and it's entirely possible to mine coins on different machines without noticing you're using the wrong miner.

[nwoolls]

Does anyone know what the best setting is under settings, miner, priority (assuming I want to optimize my miners)?

Is Real-time better then High for example? The list shows 'normal' at the top of the list, real-time in the middle somewhere, and 'above-normal at the bottom just below 'below-normal'  

Also, does the program need to be restarted for this setting change to take effect?

You don't need to restart the program but do need to restart mining. It's just the process priority assigned by the OS. It really shouldn't matter much, but I have a couple users who get better performance if they set it above normal.