Author

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

full member
Activity: 125
Merit: 100
Very strange bug: if usb bluetooth adapter conected MM or bfg does not see GPU's. Old MM 1.3.47 with cgminer work fine.  MM - 2.3.5, bfg - 3.10 win 64, win7x64, i7-4770k, 8 Gb RAM, HD 7870 with dummy plug & HD 7950 with dummy plug , main video - integrated HD 4600. Huh
newbie
Activity: 13
Merit: 0
I have been able to work round that crash by leaving the zero in the port entry box, entering the port then deleting the zero so there is always text in the box.

I've added the details of my Bitcoin pool to coin config and I can see my Icarus devices listed in the main window but the start button is greyed out. Why might that be?

Thanks for your help!
newbie
Activity: 13
Merit: 0
Hi nwoolls!

With MuM 2.3.5 under Deb Jessie x64, the following  gets dumped to the terminal as soon as I delete the 0 in the port input box of the coin config window:

Code:
System.Exception:  is not a valid value for Int32. ---> System.FormatException: Input string was not in the correct format
  at System.Int32.Parse (System.String s, NumberStyles style, IFormatProvider provider) [0x00000] in :0
  at System.ComponentModel.Int32Converter.ConvertFromString (System.String value, System.Globalization.NumberFormatInfo format) [0x00000] in :0
  at System.ComponentModel.BaseNumberConverter.ConvertFrom (ITypeDescriptorContext context, System.Globalization.CultureInfo culture, System.Object value) [0x00000] in :0
  --- End of inner exception stack trace ---
  at System.ComponentModel.BaseNumberConverter.ConvertFrom (ITypeDescriptorContext context, System.Globalization.CultureInfo culture, System.Object value) [0x00000] in :0
  at System.ComponentModel.TypeConverter.ConvertFrom (System.Object o) [0x00000] in :0
  at System.Windows.Forms.Binding.ConvertData (System.Object data, System.Type data_type) [0x00000] in :0
  at System.Windows.Forms.Binding.ParseData (System.Object data, System.Type data_type) [0x00000] in :0
  at System.Windows.Forms.Binding.SetPropertyValue (System.Object data) [0x00000] in :0
  at System.Windows.Forms.Binding.PullData (Boolean force) [0x00000] in :0

If there is anything else you need to know to fix this, let me know please!
hero member
Activity: 630
Merit: 500
No idea if this will help, but here is a sample of a reject from the log:

Code:
[2014-01-18 02:24:45] JSON protocol request:
{"method": "getwork", "params": [ "0000000166ec738cf5f3139f44a97c17a55b9e6edf39ee5fe378e5225fdabe32f8aa8827fabc620f8e951e0a36adc90d437554a5a711801c2f63efc6f50d7f23489d4c7552da2c121c29cdaf6b338f00000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000" ], "id":1}

 [2014-01-18 02:24:45] Pool 0: Rebuilt URL to: http://192.168.7.21:17707/
 [2014-01-18 02:24:45] Pool 0: timeout on name lookup is not supported
 [2014-01-18 02:24:45] Pool 0: Hostname was NOT found in DNS cache
 [2014-01-18 02:24:45] Pool 0:   Trying 192.168.7.21...
 [2014-01-18 02:24:45] Pool 0: TCP_NODELAY set
 [2014-01-18 02:24:45] Pool 0: Adding handle: conn: 0x6fc800
 [2014-01-18 02:24:45] Pool 0: Adding handle: send: 0
 [2014-01-18 02:24:45] Pool 0: Adding handle: recv: 0
 [2014-01-18 02:24:45] Pool 0: Curl_addHandleToPipeline: length: 1
 [2014-01-18 02:24:45] Pool 0: - Conn 2 (0x6fc800) send_pipe: 1, recv_pipe: 0
 [2014-01-18 02:24:45] Pool 0: Connected to 192.168.7.21 (192.168.7.21) port 17707 (#2)
 [2014-01-18 02:24:45] Pool 0: Server auth using Basic with user 'boo'
 [2014-01-18 02:24:45] HTTP hdr(Date): Sat, 18 Jan 2014 07:24:30 +0000
 [2014-01-18 02:24:45] HTTP hdr(Connection): keep-alive
 [2014-01-18 02:24:45] HTTP hdr(Content-Length): 37
 [2014-01-18 02:24:45] HTTP hdr(Content-Type): application/json
 [2014-01-18 02:24:45] Pool 0: Server zedcoin-json-rpc/v1.1.0.0 is not blacklisted
 [2014-01-18 02:24:45] HTTP hdr(Server): zedcoin-json-rpc/v1.1.0.0
 [2014-01-18 02:24:45] Pool 0: Connection #2 to host 192.168.7.21 left intact
 [2014-01-18 02:24:45] JSON protocol response:
{
   "error": null,
   "result": false,
   "id": 1
}
 [2014-01-18 02:24:45] PROOF OF WORK RESULT: false (booooo)
 [2014-01-18 02:24:45] Rejected 00003bf1 OCL 1  Diff 4/6  <-f8aa8827.5fdabe32 M:P D:6.124 G:19:00:00:0.002 O (0.247) W:25.992 (0.002) S:0.006 R:02:24:45
hero member
Activity: 630
Merit: 500
It happens on 5+ different Scrypt coins that I've tried (Tag, Lot, Doge, Net, Zed), and again, no issues using Cgminer. Currently tried on Doge, and for my logging purposes, I have it running against ZEDcoin (just released, with low difficulty, so good way to test one machine, as I don't want to waste any more hash power on the failed attempts).

Batch file used to start:

color 02
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
timeout 30
Start "SOLO Crypto 1 Status" /High bfgminer --scrypt -o 192.168.9.104:17707 -u Ugh -p boo -g 2 --auto-fan --intensity 13 --thread-concurrency 8192 -w 256 -L issue.log

Same parameters used with CGminer instead of BFGminer = success. I tried earlier versions while using MM (don't recall exact versions, but I went 3-4 months back), and that had the same result.

Ty sir! I'll see what I can bisect.

Maybe it's a sign for me to just go back to my nice and easy LTC mining in a pool. Smiley   Thank you for any insight you may be able to provide. I think I'll keep the one machine running for testing, and switch my solo efforts back to LTC using MM until I can figure out why BFGminer doesn't like Scyrpt solo mining for any of my miners. I feel "naked" just using Cgminer standalone Smiley
hero member
Activity: 840
Merit: 1002
It happens on 5+ different Scrypt coins that I've tried (Tag, Lot, Doge, Net, Zed), and again, no issues using Cgminer. Currently tried on Doge, and for my logging purposes, I have it running against ZEDcoin (just released, with low difficulty, so good way to test one machine, as I don't want to waste any more hash power on the failed attempts).

Batch file used to start:

color 02
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
timeout 30
Start "SOLO Crypto 1 Status" /High bfgminer --scrypt -o 192.168.9.104:17707 -u Ugh -p boo -g 2 --auto-fan --intensity 13 --thread-concurrency 8192 -w 256 -L issue.log

Same parameters used with CGminer instead of BFGminer = success. I tried earlier versions while using MM (don't recall exact versions, but I went 3-4 months back), and that had the same result.

Ty sir! I'll see what I can bisect.
hero member
Activity: 630
Merit: 500
My next step in troubleshooting is underway, and I have BFGminer running standalone with very verbose settings logging to file. Sadly, I have had to go back to cgminer standalone for now on most of my machines, as I want to solo mine some coins right now. I used exactly the same parameters in my standalone BFGminer test that I used in Cgminer, and in CGminer solo worked perfectly.

I don't pool mine small coins (anything under 800-1000 difficulty), so if I'm hoping I can figure this out.

When you get some time can you post those parameters along with the coins, wallets, versions, etc. either in here or in private? I'll do what I can to follow up.

It happens on 5+ different Scrypt coins that I've tried (Tag, Lot, Doge, Net, Zed), and again, no issues using Cgminer. Currently tried on Doge, and for my logging purposes, I have it running against ZEDcoin (just released, with low difficulty, so good way to test one machine, as I don't want to waste any more hash power on the failed attempts).

Batch file used to start:

color 02
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
timeout 30
Start "SOLO Crypto 1 Status" /High bfgminer --scrypt -o 192.168.9.104:17707 -u Ugh -p boo -g 2 --auto-fan --intensity 13 --thread-concurrency 8192 -w 256 -L issue.log

Same parameters used with CGminer instead of BFGminer = success. I tried earlier versions while using MM (don't recall exact versions, but I went 3-4 months back), and that had the same result.



hero member
Activity: 840
Merit: 1002
My next step in troubleshooting is underway, and I have BFGminer running standalone with very verbose settings logging to file. Sadly, I have had to go back to cgminer standalone for now on most of my machines, as I want to solo mine some coins right now. I used exactly the same parameters in my standalone BFGminer test that I used in Cgminer, and in CGminer solo worked perfectly.

I don't pool mine small coins (anything under 800-1000 difficulty), so if I'm hoping I can figure this out.

When you get some time can you post those parameters along with the coins, wallets, versions, etc. either in here or in private? I'll do what I can to follow up.
legendary
Activity: 1288
Merit: 1004
Thanks!
Now I am going to feel a bit more positive about picking up some ants.

I'll go ahead and toss out an unofficial build of 2.4. This has all the fixes from 2.3.5 merged in, and includes:

  • Added support for AntMiner U1 and LittleFury
  • Click the Utility column to display Work Utility instead
  • Re-scan devices before auto-mining on startup commences
  • Show current hashrate (in addition to the previous average hashrate)
  • Display nicer device names when possible based on driver

https://www.dropbox.com/s/ll1805ms0haydv8/MultiMiner-2.4.0.zip
hero member
Activity: 630
Merit: 500
My next step in troubleshooting is underway, and I have BFGminer running standalone with very verbose settings logging to file. Sadly, I have had to go back to cgminer standalone for now on most of my machines, as I want to solo mine some coins right now. I used exactly the same parameters in my standalone BFGminer test that I used in Cgminer, and in CGminer solo worked perfectly.

I don't pool mine small coins (anything under 800-1000 difficulty), so I'm hoping I can figure this out.

hero member
Activity: 840
Merit: 1002
I'll go ahead and toss out an unofficial build of 2.4. This has all the fixes from 2.3.5 merged in, and includes:

  • Added support for AntMiner U1 and LittleFury
  • Click the Utility column to display Work Utility instead
  • Re-scan devices before auto-mining on startup commences
  • Show current hashrate (in addition to the previous average hashrate)
  • Display nicer device names when possible based on driver

https://www.dropbox.com/s/ll1805ms0haydv8/MultiMiner-2.4.0.zip
hero member
Activity: 840
Merit: 1002
Version 2.3.5 of MultiMiner is now available for download. This bugfix release contains the following changes:

  • Fixed wrong pool and coin information being displayed when using Auto-Mining strategies
  • Fixed wrong proxy worker information being displayed if a proxy process crashes and is restarted
  • Fixed start button not enabled after scanning for hardware
  • Handle 0-byte XML files more gracefully
  • Fixed configuration files being overwritten if multiple rigs share a common configuration location
  • Fixed error using Quick Switch - sequence contains more than one element
  • Fixed additional KeyNotFoundException errors parsing pool information

Version 2.4 will be following up soon with new features.
hero member
Activity: 1036
Merit: 531
So my CGminer test was successful, I have found solo blocks without issue using it standalone on the exact machines with the exact settings as my BFGminer/multiminer setup. So now the issue is isolated for sure to that.

I have nearly the same issue, i try MM, but not for solo mining.
This is a really good soft, but after a lot of different test, i can say, that it (for sure bfgminer) increase by mini 5X my rejected share compare to cgminer.

I'll test an other version, but that's too many share lost for me.
hero member
Activity: 630
Merit: 500
So my CGminer test was successful, I have found solo blocks without issue using it standalone on the exact machines with the exact settings as my BFGminer/multiminer setup. So now the issue is isolated for sure to that.
hero member
Activity: 630
Merit: 500
Asking about Work Utility again, as this is a very important stat for miners and optimization, as you want your work utility to be as close to hash rate as possible. Utility doesn't give any useful information alone, as it is based on difficulty. I believe the issue is that WU is not in the API by default, but this is what was recommended by Luke when someone else asked:

It's already done for 2.4. If you want I can build you an unofficial version so you can check it out. It has some fixes coming for 2.3 as well as new features for 2.4, but not done yet. Hoping to finish up both and release soon though.

Thats great news!! When I switched some of my machines back to the vanilla CGminer for testing my solo mining issue, I realized how much I missed that. Tweaking your cards is much more than just hashrate, and that W/U is everything.

Once you feel you've taken this as far as you can or are willing, please email me your notes and I'll be happy to dig deeper. It will take some time to get everything setup (I don't solo mine or even run many wallets anymore) but I'd be happy to see what I can do for you.

The last thing that I can think of to do is what I'm doing right now with 5 rigs, and I'm running solo with just Cgminer to make sure that is working fine and eliminate everything except the bfgminer/multiminer combo. Then I can try bfgminer alone, but I would assume there couldn't be anything in Multiminer alone that would cause the issue, so unless you think that's necessary, I'll skip that and assume it has to be BFGminer.

If you can think of anything else that I should try, I certainly will. I am determined now to dedicate a few machines to figuring this out, as I want to have the ability to solo mine again inside MM.
hero member
Activity: 840
Merit: 1002
I've not been able to get Multiminer 2.3.4 mining under Debian Jessie amd64. I've installed mono-complete (v3.0.6 I think) and bfgminer 3.8.1 from the Debian repos. I open the 'configure coins' window, add Bitcoin and then as soon as I delete '0' from the ports input box to input the port for the pool I use, MuM segfaults.

Can you paste the full call stack left in the terminal after it crashes?

The main reason I'd like to use MuM is that it seems to support restarting of suspect mines. I have a load of Icarus block erupters attached to my mining box and, under cgminer at least, they often become zombies after a few days then I need to manually restart cgminer. I've not tried them with bfgminer yet but I presume this the sort of problem MuM's 'restart suspect mines' option is designed to get around?

Yes it should take care of that.

Also, I've seen a screenshot of MuM where it appeared to be using cgminer instead of bfgminer. Is/was that an option or is it strictly for use with bfgminer?

I haven't supported cgminer since 2.0 - just no time and bfgminer and cgminer are getting to be too different. Instead I focus on making the integration with bfgminer top-notch and I now contribute code to bfgminer as well to make sure it is a superior solution for mining.
hero member
Activity: 840
Merit: 1002
Asking about Work Utility again, as this is a very important stat for miners and optimization, as you want your work utility to be as close to hash rate as possible. Utility doesn't give any useful information alone, as it is based on difficulty. I believe the issue is that WU is not in the API by default, but this is what was recommended by Luke when someone else asked:

It's already done for 2.4. If you want I can build you an unofficial version so you can check it out. It has some fixes coming for 2.3 as well as new features for 2.4, but not done yet. Hoping to finish up both and release soon though.

On another note, I'm at wits end on my solo mining issue, I cannot get it to work, and the rejects shown are unbelievable. I'm not new to solo mining and have always worked fine, but I hadn't tried it since I was last on the earlier version of MM using CGminer. I've downgraded BFGminer to early versions, turned off donations (sorry, I was trying to make sure that didn't mess up anything, turning them back on once I finish troubleshooting), and now I'm back on a handful of machines running CGminer standalone solo mining. I'm hoping I get a reject on one of those, but this is happening on multiple coins, and does not appear to be an issues outside of my multiminer/bfgminer rigs, but until I find a block, I can't confirm 100%

Once you feel you've taken this as far as you can or are willing, please email me your notes and I'll be happy to dig deeper. It will take some time to get everything setup (I don't solo mine or even run many wallets anymore) but I'd be happy to see what I can do for you.
hero member
Activity: 630
Merit: 500
Asking about Work Utility again, as this is a very important stat for miners and optimization, as you want your work utility to be as close to hash rate as possible. Utility doesn't give any useful information alone, as it is based on difficulty. I believe the issue is that WU is not in the API by default, but this is what was recommended by Luke when someone else asked:

When overclocking individual chips, it would be useful if I could calculate the average valid hashrate from work utility. Unfortunately, the procs API response only lists utility, not work utility. Adding either time elapsed (which could be used in the calculations with Diff1 Work) or work utility to the procs response would be helpful.

And before you say "just use average hashrate * 1-HW%", I'll note that at least broken bitfury chips sometimes report inflated hashrates. For example, a chip @ 2.2 GH/s doing 33% errors never barely manages to do even 50% of the diff1 work that normally functioning chips do @ 2.2 GH/s. These kind of problems are why it would be useful to have the ability to derive a hashrate from actual work done, for individual chips. This is easy to do for the whole instance from the summary response, by just calculating (Work Utility)/60*2^32.
Work Utility is Diff1 Work / Elapsed


On another note, I'm at wits end on my solo mining issue, I cannot get it to work, and the rejects shown are unbelievable. I'm not new to solo mining and have always worked fine, but I hadn't tried it since I was last on the earlier version of MM using CGminer. I've downgraded BFGminer to early versions, turned off donations (sorry, I was trying to make sure that didn't mess up anything, turning them back on once I finish troubleshooting), and now I'm back on a handful of machines running CGminer standalone solo mining. I'm hoping I get a reject on one of those, but this is happening on multiple coins, and does not appear to be an issues outside of my multiminer/bfgminer rigs, but until I find a block, I can't confirm 100%


Some info from log:

Getworks=4963   Accepted=0   Rejected=18   Works=3361   Discarded=1602   Stale=0   Get Failures=0   Remote Failures=0 Diff1 Shares=18   Proxy=   Difficulty Accepted=0.00000000   Difficulty Rejected=8654.25188256   Difficulty Stale=0.00000000   Last Share Difficulty=0.00000000   Has Stratum=false   Stratum Active=false   Stratum URL=   Best Share=286   Pool Rejected%=100.0000   Pool Stale%=0.0000



newbie
Activity: 13
Merit: 0
Hi nwoolls!

I've not been able to get Multiminer 2.3.4 mining under Debian Jessie amd64. I've installed mono-complete (v3.0.6 I think) and bfgminer 3.8.1 from the Debian repos. I open the 'configure coins' window, add Bitcoin and then as soon as I delete '0' from the ports input box to input the port for the pool I use, MuM segfaults.

The main reason I'd like to use MuM is that it seems to support restarting of suspect mines. I have a load of Icarus block erupters attached to my mining box and, under cgminer at least, they often become zombies after a few days then I need to manually restart cgminer. I've not tried them with bfgminer yet but I presume this the sort of problem MuM's 'restart suspect mines' option is designed to get around?

Also, I've seen a screenshot of MuM where it appeared to be using cgminer instead of bfgminer. Is/was that an option or is it strictly for use with bfgminer?

Thanks for your help!
hero member
Activity: 840
Merit: 1002
MuM stopped working. I uninstall 2.3.4 and reinstalled and it still will not launch. I uninstalled and installed 2.3.3 and it won't run either. Any idea what might've happened?

Any errors at all? If there are no errors at all and it crashes before opening, this generally means you have a bad XML config file in %appdata%\MultiMiner. Navigate there in Windows Explorer and look for an empty XML file and delete.

There's better handling coming for this in a future version.
Jump to: