OK, but if everything is dynamic (when you edit configs, or hashrates, power consumption...etc), don't see a reason why this part is different.

It's very useful for diagnosing problems on rigs. Example:
1) waiting for rent to stop
2) ALT + q
3) edit MRR config file to disable
4) rerun MM - to see the rig in action

By improving it you cut down 2 steps, it's much faster.

Another quirk probably related to group api,...you need to bring rig down for maintenance, you set the "Enabled" flag as false, and you exit MM throught Alt+Q...when it's shutting down it lists as the algos are disabled when you shut down,...but in reallity they are not. If you go to MRR it still says "Available". So I had quite often problems when servicing rigs,...well on the plus side it definitely made me work faster But another quirk, that might be worth looking into.

Another annoyance: every now and then I get following warning when MM restarts "MRR: Not authorized! Check Key and Secret."
Then to speed up, I change something - any value in MRR.txt config, restart MM and usually it connects again. Sometimes it takes 2 or 3 tries...few times the reconnect was too late and already lost a client because of 20 min no hash policy on MRR. How does that work? Can we improve it and make it more reliable?

OK, Thanks.

Here's anothe one for you: there's an issue with MRR if two orders are submited to the same rig within 2 min of time frame,...one order if left out. This happens to me quite frequently and it's annoying. I've reached out to MRR support and this is their response: "you should look into using the rig group api, it will make sure that only 1 gets rented at a time". So is it possible to implement group api so this doesn't happen in the future?

hi,

can you pls add new VTC fork - VerthashMiner (Verthash algo) and also add MRR support on it.

Thanks

Yes that would be helpful.

When there's a new miner update hashrates usually don't match,...so to bring this up on demand would be very helpful:

MRR calculations...where it says in red if the hashrates differ - which is usefull when you're upgrading.

Hi,

I have a request, is it possible to add additional shortcut,...like M for clean miners,...for MRR calculations when they show up every few minutes? It would be very helpful when you're updating the miners?

Thank you.

OK, and "Automatic Pricing" on MRR has to be set to "No", in order for this to work. Right?

Hi,

Question about MRR,...if you mess on MRR with settings for each miner, regarding price,...how do you turn it back so MindMiner sets the default price according to what percentage? Automatic Pricing set to No?

Thanks.

I'll try to hunt it down,...here's one example:

1) lolminer 092 - triple parameters user, pool, password are forwarded so it's not working
2) yescrypt-9 - no pool parameter is forwarded

I'll try to find more.

Tried it and same thing. You have to replace everything in order to make it work.

There seems to be an issue with latest update. The url of the pool is not correctly passed to the miner, it's blank. Please fix it asap.

Thank you.

OK, thanks didn't know about beta repository.

Can you explain, where did you get gminer-135 release if it's not released yet?
There's only 134 release on github/mega?

I must say I'm impressed with this profit miner.

Feature request: specify which devices to use? For those of us who don't want to use all cards in a system?

Currently even if you manually specify more than 8 devices with -cudadevices flag, are not used.

Please add support for more than 8 GPU's.

Thanks for response.


Why not allowing both calculations at the same time MPH and NH, so people have the feel for the market?

One more for you:
In case of multiple rigs with multiple cards, 1060 some 3G and 6G (also different vendors). In order to maximize profit in current market conditions to max profit you need logic from nicehash, which benchmarks every card individually then creates the strategy for max profit. In following example: 3 different cards, Zotac 1060 6G, EVGA 1060 SC 3GB and EVGA 1060 6GB,...it's using multi matching,...so on NH latest beta, 12 gpu system, current estimate NH 8.8 usd vs MM 7.9 usd - yes we all know rough estimates, but still noticeable difference.


This is using ethash, with excluded 3gb cards,...now one variant is to use the rest of the gpu's with BEFORE/AFTER script to run separate instance of a miner, but you have to set it up manually, tomorrow or in next few hours everything changes.,..so it's not a reliable system that needs constant "maintenance". Any ideas?

After benchmarking is the hashrate final? Or when it's running it's constantly updating the values? Valuable information for tweaking the systems.

@Quake4  Really like you're multiminer, i'm testing it on one of my rigs, will give you later a full review and possible suggestions for the future.
Do you need to do anything special in order to include full nicehash support? Like cryptonightv7 and ethash are missing from calculations,...MPH is calculating properly.

1) What about adding support for nicehash excavator on their pool? Yes I know you're not allowed to redistribute it, but as an option so if there's a big order on nicehash then everybody gets a piece. This way you have one multiminer that does it all.
2) How's is mining fee implemented?

Keep up the good work.

I've already tested this, you can read it in message if you read it properly unfortunately it still doesn't work. I have to use watchdog=false because on systems with 8+ gpus you cannot run this miner properly, because the cpu usage in the beginning is too high - first 2-4 min that the miner needs to initialize it self to max speed,...then the cpu lowers to normal state 40-60% on low cost G3930. I've reported this bug already and few others too.

Now what's even more bizarre regarding this connectivity issue:
- yesterday: half of the mining farm was still working with bminer properly, the other half still had connection issues, so i switched back to ewbf with problematic rigs
- today: even the other half couldn't connect,...so switching back to ewbf/dstm permanently until this issue is properly addressed.