Topic: [ANN] lolMiner-mnx, Mining MinexCoin(MNX) New version: v0.4 (July 22) - page 45. (Read 30772 times)

Although i noticed that when i run more than 4 gpus i have to drop the OC a lot for last 2 gpus because it drops core if OC is same as other cards. When I stop 1 card and try again then it starts mining with the card that dropped core.

Update: Now the last gpu (segmentation fault (core dumped) with no OC.

Update 2: Tried again with no OC and started mining. Im not sure whats going on

v 0.11 with enable-nv-hotfix.

With or without "--enable-nv-hotfix"? Usually this command was meant to allow more GPUs at full speed.

Using Ubuntu, 1080Ti, 1 instance 20k Sol/s. 3 instances 15k Sol/s each. 6 instances crashes rig.

Thats much less then it should be. Can you give more informations, i.e. is that one card or many, with the hotfix switch enabled or without and what driver version? Until now I did not see that much difference between Windows and Linux version and thats surprisingly low for a GTX 1080   Maybe you can give us the whole command you use to start - the more information I have the easier to help you and to debug.


Thanks for feedback! I do not have more then 2 GPU at hand for testing. Therefore nice to see that this really helps for larger rigs

Is this displayed or pool hash rate varying? The one displayed by the miner should be constant. If this is not the case then something goes wrong with the lower CPU usage fix. This one tries to sleep the CPU for a certain amount of time depending on Kernel execution. Now if system is under very high load the measured values for kernel duration may vary to much for the fix. How much CPU load do you have running all your cards simultaneously?

Some feedback for updated miner:

So far pretty stable. Been running 25 min for now no crashes but lets see if it stays alive for 24h.

6x 1070ti 0-4 gpu OC core: +150 mem: +550. gpu 4 oc core: +50 mem : +500.  gpu 5 oc core: 0 mem: +400 Powerlimit: 95w

Speeds are around 13k-13k5 Sols so big upgrade from optiminer and now all gpus mine with same speeds and no hashrate drops.

Edit: Running  on Ubuntu 16.04

version beta v 0.11
Windows 10 64bit, GTX1050 5.3-5.4 kSol, uptime 1 hour. CPU usage less than 16% (prev version 25%)

The performance drops A LOT randomly, in my 1060s from 10000 to 2200 sols

Win 7 64 bit GTX 1080 only 650 sol/s...... and i7 7700 - 100% load.
https://imgur.com/a/jdBOL

great!

Create two files. One for starting the miner and one starting the first file for each GPU, something like this:

(change the 'GPUs' variable to the number of GPUs you would like to use for mining mnx)


This will start lolMiner-mnx for the number of GPUs specified and restart when/if the miner crashes.

Thanks, corrected  


Danke sehr ^^ Den hab ich gefühlt schon ewig - beim Zocken war ich zwar nie sehr gut aber hab einige gute oft kreativ geändert, daher der Einfall. Aus der Zeit kommt auch noch das HD 7770 system das ich zum testen verwendet habe. Wie die Zeit rennt 

--enanble-nv-hotfix should be --enable-nv-hotfix.

Well that is true, but this is part of the game. Faster mining software often helps the early adopters (because they can mine with low diff and high hashrate). Later on when everyone is mining with high speed we will be back to normal profitability. But for MinexCoin it is better this way. Why?
Well we see now what hashrate is possible. Assume that anyone that wants to corrupt the coin is able to write a mining software much faster then the existing ones. If then the hashrate of the network is low because the algorithm is not that optimized or because only Linux miners are mining then it is easy to collect enough hashrate to try an 51% attack on the coin.
Now the hashrate of MinexCoin will increase and the software will work (hopefully stable in future) on multiple platforms. Then is also gets harder fining a better implementation or running an attack. Overall this strength the coin. Now lets hope no one does a ASIC for Minex - Equihash 96/5 memory requirements are rather low for a GPU only coin. 

I will write some FAQ lines for this during this afternoon. Or hurry implementing the multi GPU one instance use ... or better both

Thank you for your software. Anyway the difficulty will go up a lot soon thank to these performance (and windows user).

You have to use --device 0 in one bat and --device 1 in other bat!
RTFM...

So, as promised it is time for an update:


Here are the binaries for version beta v 0.11:

Linux 64: https://drive.google.com/open?id=1l7TXYEfXbdGgkpQbIQAz9JGaV-5vYVdF
Windows 64: https://drive.google.com/open?id=1remeVpaiVhqKkKZyo966xiVRsP_4OfeZ


Changes:

Added a new command line parameter "--enable-nv-hotfix".
The parameter will reduce the required CPU utilization on Nvidia graphic cards. If you required 100 + x% CPU utilization (so one full core and parts of a second) it is likely that now you will need 10-15% + x. I can not get rid of the x because  this is for checking if the solution is below the target. On my 2.1 ghz CPU with a GTX 1080 attached CPU utilization went down from 115% to ~20%. This will also help running multiple instances for large rigs. Unfortunately one will loose about 1-2% of mining speed on Nvidia hardware when enabling the switch. Therefore - and because the loss may be even larger for other vendors - the hotfix has to be enabled by command line for each instance.

Added an automatic reconnect when the connection is broken.
When a share is submitted and there is no acceptance message by the pool for the next 10 seconds the miner will reconnect to the pool in order to get back a stable connection. This helps the miner not to hang.


By the way: I think I found one glitch in the windows version causing the crash that happens after a while. This seem to happen when the pool sends a new job but not with enough parameters (jobId, time, merkle_root....).
The fall back method seems to work fine on Linux, but causes the crash on Windows. Therefore I would recommend testing different pools as long as this is not fixed, because the rate is not equal for all pools. I will try to get this fixed in next version.

By the way beside bugfixing the next features I would like to implement are (in order of their priority):
- The opportunity to run it on multiple GPUs with only one stratum instance.
- A handbrake function for the miner. More concretely a switch that lowers the hashrate but such that the graphic card is not busy 100% over the time. May help for rigs with temperature problems or overambitious graphic drivers that kill tasks that cause too much GPU load.
- An algorithm toggle. The algorithm used can be configured to create different memory pressure on the card. Changing from default behavior may improve the speed graphic cards will less compute cores per shader processor as NV Tesla P100 or AMD Vega series.  

I hope that I can make it implementing at least one feature and some of the left known bugs till next week

Ps:
Current hashrate of all lolMiners out there: about 820 ksol/s (1,5% market share)

dear friend of mine and you can write me examples of bat files that are valid for 2 GTX 1060. if not hard
I try and I for some reason do not work

My 1 x 1070 run for about 3 hours then crashed.

Lol

Of course, te second bat should point to another GPU, not the first one