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.

@realbminer

Today there was a problem with the zenmine.pro mining pool,...don't know what was up but after investigating I've found out that bminer still has some sort of connection problems...see the picture below,...all this time the GPU was at full load,...although it didn't had a proper connection to the pool and I couldn't see it on the minning pool. Then I've switched to ewbf/dstm, both miners connected immediately and are working properly?

I use following in a batch file:
I've tried without SSL connection to the pool, and the result was the same. Everything that's written in a console is written also in a log file,...so nothing new can be obtained from the log file.



This is a huge issue! I've lost at least half of the hashrate because of this bug.

@realbminer: Because all the miners control miner/gpu crashes differently I prefer to do my own pool switching in simple loop and task scheduler keeps my gpu healthy. Now here's the problem, according to you're reference guide:


In order to achive this,...to control everything our selves,...the following should work:

But unfortunately it doesn't bminer.exe keeps running even if you kill it manually with admin privileges. I've tested it with 5.2 version, haven't had the time to test 5.3 yet.
Can you please elaborate how to effectively control it our selves. I've tested it on Win 8.1 and Win 10. On ewbf miner --eexit 1 works perfectly.

EVGA GTX 1080SC, +100/+500/87pl around 155-160w

@realbminer: What does this error message mean?


Is there a way to reduce the CPU usage of this miner? I've used the "-gpucheck 0" to get the 8rigs to work,...but for 12 rigs it's too CPU intensive and it it closes/crashes without any warning.
What's the command line to get the watchdog disabled? "-watchdog false/0" won't work.

It looks promising, will test further, finally some competition in equihash algo.

Everyone has to overclock/underclock in order to max the profit,...most of the miners love to push the cards to their limit,...i personally love to find the perfect balance for each card,...ideal performance/watt ratio,...but in both scenarios you need a stable miner, which is flexible for stock and overclock/underclock settings,...it has to be stable otherwise it's no good,...that's the main reason I'm still sticking with ewbf,...because it's unstable on higher clocks,...but it has a good potential

On my tests i've came to the same conclusion. I've received the same message "recv failed: 10054" on machines, that are heavily OC,...on the same system same parameters ewbf runs stable,...on 2 rigs I also received following error, but I think it's all related how miner is handling gpu driver crashes:
https://pasteboard.co/GQec9U9.png
Also on my rig with 7x1080ti I'm getting only 2800 sols, instead of 5000 sols...it's a windows box with a cheap Celeron G9300.

You're miner looks very promissing, and I'm prepared to deploy it to the rest of my boxes,....but you need to improve how miner responds to gpu driver crashes.
Thanks for you're work,...it's about time there's some competition in this space So go for it!