Theoretically the miner can run on CPU - currently this is disabled (it only sees GPU devices), but for any CPU where there is an OpenCL driver it could run. Maybe I enable this experimentally.
As for the checks: in release version I disable all checks and pray for the algorithm to work correctly, since else CPU load would be very high. There are rare cases where flipping memory bits can invalidate a result or make the miner stuck, but also rare cases in which the miner can produce a faulty share. I will try to reduce this cases in new code.


Thanks for mentioning it, I will add it in next version.


For the Vega it would make sense reducing core a bit, but keep memory up. Then undervolt the core, so the card does not throttle clocks due to running into power target. Similar for the RX series. I heard someone to have about 19 sol/s @ 95W on 480 - with some uv that should be possible and would look much better.



By the way current status:
First of the 6 new GPU codes went today from development to testing - but I will not tell you which Well its one of the Nvidia codes. Later today then start of the corresponding AMD codes.
Further this week SafeCash will rebrand to Genesis (GENX) including new personalization string. I plan to update lolMiner at the end of the week with the new strings (and BitcoinRm) plus some bug fixes (this command line stuff with = sign and one sources of 0 sol/s but for 192/7 on AMD).
See you then and keep posting your wishes and suggestions

Look to this post of me just above: https://bitcointalk.org/index.php?topic=4724735.msg44961610#msg44961610
There is a way to get around this bug in commandline, that I will fix with next version

Haha yea your right. Glad that "consistently" does not say anything about the spread ^^ But the new code will come and its looking good we can push the 8G further. Well both cards in fact but also some 3G cards

By the way, except for "please add support for free personalization string" no one yet followed my voting on the 0.5 features. No opinions on that?

An older version of this miner is included into HiveOS - I think we must talk to the devs there to include the more recent ones to it, too.


Currently it is not possible, so best is to tell me about the coin and I will add it in the next version. But I currently consider one profile to allow a freely set personalization string since this was requested multiple times. Only problem I have with this is that in this case I can not do individual coin settings of other parameters. Well, will find a solution.


I do not know much about ethos. How do you start / configure the miner there with general settings? I am sure we can figure out how to do it.


That is a good question   Can you try to run clinfo.exe (is shipped with the AMD driver) and paste me the output into a private message? The incompatibility message usually comes when some memory check fails. Lets see what clinfo reports, then I can tell you what is wrong. As a first guess: some drivers limit the amount of memory that can be allocated in a single memory buffer. For AMD it often helps to execute
before you try to start the miner. This should allow the miner to use all GPU memory that is there.



Ouch, you found a bug! The problem is that the "=" sign is wrongly threated in the miner.  I will fix this in next version. As a quick and dirty cure open the "user_config.json" file and add after the "defaults" section the following:
and then start the miner with

That should work.



For most Nvidia GPUs I have to admit that EWBF is currently faster - he just did an amazing job, especially at 144.5. But I am currently working on the next generation of kernel codes and can promisse: I am getting closer .... muuuch closer. Maybe ... lets see 
That said, for AMD GPUs and 144.5 this is currently the only miner and for 96.5 and 192.7 this miner is consistently faster then Optiminer - so probably for AMD users the best avail option.

The Equihash 96/5 (MinexCoin) will work. If you got a 2G GPU and run it headless it may be that with the mem-saving variants 144.5 is also possible, but its a close call.

So, I did some more coding last week and so there is an update: lolMiner 0.43

Download Links:
[Lin 64]: Click me (0.43 for Linux)
[Win 64]: Click me (0.43 for Windows)

here are the virustotal reports for the two executables:
Linux: https://www.virustotal.com/#/file/dc2efb304b84ab92d1f085ecf61d1e470ce366f3801233072bead2809b0b3c9b
Windows: https://www.virustotal.com/#/file/1325784f9a9ff11bb077cc66937b66c28422d4e71dd46ae959ccad87d7799065

Hint: As you can see the Microsoft Windows defender detects the mining software as "PUA:Win32/CoinMiner " (Surprise ... its mining coins   ). So if you have trouble with it better replace the defender by any other anti virus (e.g. I use Avira AntiVir, which is also free) and you are fine.  


Detailed Changelog:

Added 192.7 Algorithm with coins Zero (ZER) and SafeCash (SCASH)

lolMiner now supports the Equihash 192.7 algorithm. The two coins supported are Zero (ZER) and SafeCash (SCASH). At the moment the miner requires 3.7 GB GPU memory, so 3G cards are not supported. Nvidia 4G cards can mine with new “DISABLE_MEMCHECK” switch (see below).

There should not be a performance difference between 4G and 8G GPUs!

Expected performance:

AMD:
RX 550 (4 G): 3 sol/s      (to be confirmed)
RX 560 (4 G): 5-6 sol/s
RX 570:   11-12 sol/s
RX 580:   12-13.5 sol/s
Vega 56:   18-20 sol/s

Nvidia:

GTX 1080 (stock FE): 20 sol/s+
GTX 1080ti: 30 sol/s+


Added support for zergpool Equihash 144.5 auto profit switching

You can now connect to equihash144.mine.zergpool.com to use its auto coin switching / auto exchanging capacities. The needed setting is “COIN” : “AUTO144” or -coin=AUTO144


Added switch to disable memory check

Use “DISABLE_MEMCHECK” : 1 or -disable_memcheck=1 to turn of the miners compatility memory checking. This fixes a problem with the Nvidia driver not reporting enough memory for Equihash 144.5 (3G & 4G cards) and 192.7 (4G cards)

Note: Disabling the memory check also implies the miner can no longer check how large the workbatch is allowed to be, so DO NOT USE THIS WITH EQUIHASH 96.5 (MinexCoin) . It will kill your performance.


Fixed support for open source Linux drivers

lolMiner should now be able to start on the open source Linux drivers but the performance is very much untested. Also for 144.5 and 192.7 the memory check may need to be disabled.

Fixed a bug with miner not starting without config file

As said, you now can delete the user_config.json and run completely without it by using the command line only. Note that the config file still has the advantage of storing your settings for multiple coins in one file as well as fail-over pool support. The filename and the used profile of config file can be changed by parameters (see manual).

Fixed a bug with miner not starting (hanging in setup)

It now can take a minute or two for the fail-over routine to kick in, but this should fix the problem.

Shortened the target printing to the first 16 characters

Previously printing 64, making the lines unnecessary long.

Added some colors (very subdued )

Stratum messages of new job, new target and submitted / accepted shares are now print in a green tone and the long statistics in some not too bright cyan. If you see a red message thats a stratum error message or a case where the server responded  {"id": 4, "result": false, "error": null}, which means a share got not accepted.

Know issues:
Sometimes the 144.5 and 192.7 codes run into the 0 sol/s bug even without OC. I hope to get rid of that in the next code iteration.

For some Nvidia GPUs specifying “WORKBATCH” : “HIGH” in config file leads to 0 sol/s from start. From command line it works fine. Investigating why.



Question is now: What am I coding next for 0.5?

Here I would like to have your feedback!

There is one thing I will do any ways: I tried a new code variant with the 192.7 miner that is there applied in the first two rounds of code. It turns out that this works quite well and so I would like to bring this for 96.5, 144.5 and 192.7 for both vendors next. This also will likely reduce the memory consumption of 144.5 to 2.4 G and of 192.7 slightly below 3G, so the 3G cards are back on board for 192.7.

But after that? You may decide!

Here is a list about the potential list of what I could do for 0.5:

- 210.9 (Aion) mining code
- 200.9 (Zcash, …) mining code
- A memory saving 144.5 variant (sub 2G, approx 10 – 15% slower then the large memory one)
- A memory saving 192.7 variant (sub 2G, approx 25 – 30% slower then the large memory one)
- An HTML version of the API (viewing)
- Coupling of multiple miners, so  API of one rig can show stats of whole farm
- Re-Design of stats module & API, e.g. logfile output and so on … need some more ideas here, comments welcome!

Regarding the last point in list: I definitely will never change fan speed or clocks in the miner, because this is responsibility of the driver or external OC tools. But what I could try is temp readings and an emergency switch off at high temps or so … do not know.

As said the main priority lies in the updated mining codes. That will take a while. Therefore I would say everyone commenting here or sending me a message in either telegram or discord is allowed to state two things from the optional list. I will evaluate in two weeks (Sept 12) and then work the list from top to bottom

Have a nice day all

As stated above in this thread: you can not through the miner since I won't take the responsability for such a function. If your card gets so hot either part of cooling or fan setting is broken or you run far too much oc. Pls set fans and clocks with driver or afterburner.


Well a simple stat reading API is there. What functionality else would you like to see?

My miner does, its all OpenCL here ^^
Well your card has 4G, so the driver reports max usable memory in total is 4G, but max that may be in one region is 1G (1/4 th of it) ... but 144.5 needs one region with 1.2G currently.
For the next release I plan to introduce a switch bypassing the check (on own risk) but then your 3G and 4G cards will work

Depends a bit ... it closes the gap between 4G and 8G cards. Atm my code uses 3.6G and does on average 12.7 sol/s on a RX 580 4G (headless) - the 8G model will only be barely faster, maybe 13 sol/s. I think this is not so bad compared to optiminer ^^



Well we have to distinguish here between memory available and the memory that the driver allows us to use in a single buffer. For some reason the Nvidia OpenCL driver limits OpenCL that a single memory region may be at most 1/4th of the total memory in size. That said: the 144.5 miner code uses 2.8G, but requires that two buffers of 1.1G are created (and a 3rd with the missing 600 mb) ... so what happens here:
The check for enough total memory passes, but unfortunately the one for maximal single allocation fails.

Interestingly I just found out that CUDA has no such limitation and also sometimes it seems possible to allocate more then "CL_DEVICE_MAX_MEM_ALLOC_SIZE" tells on Nvidia (but not on AMD ... there it is a hard limit, but its often much higher then on Nvidia) ... so maybe I can do an option to ignore memory check on own risk ... hmm

Wtf... thats strange. The miner never writes ti the file. You unziped and then opend in text edit? When you save tten it should be saved and modified, everything else would surprise me!


Comming within next 4 days Code just entered testing
I think you mean scaled by 1000 ^^ RX 580 does 20 to 22 sol/s on 144/5 but 11000 to 12000 on 96/5 ^^
Expected is 96/5 to be approx 400 to 500x faster then 144/5 from theory. That fits pretty well

Well I will have a look into this zergpool stuff. Will see if I find a specification to their personalization string stratum modification.
And yes, the 192/7 miner I did some time ago will be merged into this product, but with a new mining code that should run on AMDs, based on the current 144/5 code we have here. From the numbers I have the estimate for the 580 I have, running 22 sol/s in 144/5 I would say the 192/7 could run 13.5 on it. So overall range for 580 should be 12 to 14 depending on clocks and concrete card.
No idea yet about what this code does on Nvidia. Will start with an AMD code, because for Nvidia there are good alternatives on market.


Damn it, that was my fault ^^
It is not -server=, but -pool=btcz.suprnova.cc
That should work better

For the latter I pray, too xD
Well as for colorful stats ... maybe I will do so, will see ^^ Would also a html stat page make the job for you? Currently thinking how to extend the API... but first more / new mining codes
But: In my opinion you should check your OC settings. If the 5 cards do 115 they do 23 sol/s each. Thats not bad, but I would rather try to lower oc / try to under-clock or run lower voltages. 1100 W for 5x580 is pretty much. Ok, do not know about your CPU and so on, even if they draw 100 its too much. Many eth mining rigs run at -0.2V under-volt and 1150 / 2150 clocks and less (instead of the usual 1350 stock clocks). It may be that then your rig does rather 100 sol/s then 115, but if then only uses 600 to 650W instead of 1100 its definitely a win in profitability unless you have free electricity.



This does not seem too bad. Lets assume you have the username "Lolliedieb" on suprnova with a configured worker name "lolRig" and password "x" there, then you have two opportunities to configure in command line. First:

Second:

In case that $RIGNAME is a properly set environment variable "-rigname=$RIGNAME" should work, but did not test this.




Can you specify what your problem is? Maybe we can figure out together how to do it.



Currently I give a bit priority to 192/7, but 210/9 will come as well. Promised, but do not know yet when. I know I am somehow much slower then ewbf but I believe he does this full time and he has only half as much code to write, since its only one GPU vendor ^^


Hmm ... currently no really good calculators I guess. At least non featuring all of the coins that work with 144/5. Maybe a point to start is coincalculators.io, which at least features BTG, XSG, BTCZ and ZEL. But there you have to insert your speed and watts manually.


-----------------------------

Some general comments till now:
Currently approx 10k sol/s are produced for 144/5 algorithm for all coins together and I earned so far approx 70$ from this miner (from start, although rate increased 4x since 0.42 is out). As for 96/5 (Minexcoin) approx 30 Msol/s are currently produced with this miner.

Yes, the MinexCoin code has some flaws currently, the NVidia more then the AMD. But new code is in the making for 0.43


ROCm and the ordinary driver are definitive different - at least when I use the rocm offline compiler I get very different register counts. I will see in instruction sets if I see something suspicious. That said: next week a new testing GPU (RX 580) arrives here, then I will set up a Linux box with multiple drivers (The amdgpu-pro, free clover drivers and the rocm), so I can better compare them and see how different they behave. That said, next side hits same target:


Found out today why the free Clover drivers do not work. Will be fixed in 0.43


Hmm - which algorithm causing these problems, 96/5 or 144/5?
One possible reason could be (virtual) memory size in your rig. Both algorithms use a large amount of memory on GPU. That said the AMD Windows driver has the strange habit to use the same amount of RAM as allocated on GPU when creating the memory buffers. So running 8x the 144/5 algorithm requires the sum of your virtual memory + available (free) RAM to be at least 8x3GB = 24 GB. If it is less the miner is not able to allocate memory for all devices. After some start up phase the drivers free the RAM and thus the required amount gets less. Thats why a 2nd instance started a litte later on the remaining devices may work for some Rigs.


I have some ideas left what to try. Not such a big jump again, but I would love to see RX 580 doing 22 sol/s now to jump over 25 ... that may be feasible and I will definitely try to make it possible

Currently you can not and I think that will remain so for a while. Why?
Well because there is no way doing that for AMD and Nvidia for all OS (Win 7, Win 10, Linux) the same way.
So the codibg would bind a lot of capacities at my side (I develop this miner alone alongside my dayjob and family) that I rather spend for creating better minibg code. Furthermore it is a matter of resposability. A corrupt kernel code can make a rig hang and can make it require a reboot, but thats it. A bug in overclocking or fan setting routine can physically harm hardware - that I do not like much. Maybe I will do temp reading in future and provide it over the API but I do not think fan or OC setting will come anyhow soon.


You are running with config file? Then you can modify the profile of the coin (or default section) by adding
For example to run on first and 3rd GPU but skipping the second. Note if you put this to default section it will be overwritten by a devices entry in the individual profile.
For command line use it should be doing the same thing.


Hmm something is wrong here. The speed you see is much higher then I would expect for this cards - I rather would think about 30 to 35 to be realistic.  No real idea why at the moment but I think something in tge filtering is broken. The miner after last round checks the solutions and filters out incomplere ones. Seems that does not work here and more solutions pass the check then it should. No idea why, but this is not good.

The warning message you got is no problem. This has something to do with a bit fancy pointer magic in GPU code ^^ But I wonder: this messages should not be displayed - you are certainly running 0.42? I think thats an older version.


Doesn't work at yours? What driver you use for the vegas, the ROCm or the amdgpu-pro?
I have no vega myself, so can not trst directly but with some detail info I think we can debug it


I think there os a bug - your 30 to 33 sols / s is more realistic and in region so I am shure the solutions are all valid. I think in his case something is broken, but will have to see what exactly.
Hope in future versions to put some sol/s on top of cause. New code is already work in progress

Ah ok, what I see is my card runs with stock clocks, so 1366 MHZ - that could explain at least a few %. But likely your setup is more energy efficient
Lets see if we can still find a few % for you by writing better code

Depends... when 580 can do 22 and 1060 does 26 - they are not too far appart ... same as with 33 (vega 56) vs 1070 speed.

Atn mining is not that profitable it used to be half a year ago with prizes up, but at new versions sol/s it should be profitable - of cause depends on coin and energy price.



The miner has a simple api. Zergpool stratum? Whats different there?


Of cause its almost always possible, but the jump will not be so big again. Maybe 2 to 3 sol/s on top for 144/5? Ok, maybe more but as with every trick the dev has to find it first



Thats odd - before yours was much faster, now slower.  Hmm ... most changes targeted the memory controller, maybe different vendor of mem chips?
My testing gpu is a saphire pulse 4g at stock clocks, what is yours?

Unfortunately I have no opportunity right now to test on the free drivers. Usually from the used code it should work on them but I do not know the memory allocation rules on this drivers. Clinfo should never the less work with the free AMD drivers as well, so if you could run it and send me the output in a private message that may help me a lot fixing this


Thx for reporting
I am still amazed how well the R9 290 does - I mean ... this autumn its 5 years since release and still they are close to 580 series. Who bought such a card back then did get a lot of value for bugs ^^

We had tests running on a RX 560X, so I assume the 560 should also work. How much memory you got in the GPU? We need at least 3G, better 4G for this Algo, when it is a 2G it will not work.
If it has 4G, try running "clinfo" and head out for "Max memory allocation" - the number will tell you how much of the GPU memory can be allocated for a single memory object. The least size we need here is 1140887552 bytes, equivalent to 1089 MB. It could be that your card driver restricts to 1024 MB. If this is the case on AMD GPUs you can try to export two environment variables:


This will allow the driver to use larger memory buffers - maybe I should include that into the run_miner.sh scripts ^^

Hope this helps you

That reminds me that I forgot to mention what will come next xD
Well in fact I am not yet certain. It will either be Minexcoin code for NVidia or 192/7 code for AMD. Any ways I will focus right now on improving the mining code rather then new features, since the rest of the miner - well I would not claim that there is no headroom for improvement, but I think it is good enough for the moment. Focus should be fast(er) mining

So, after "some" tuning its there: lolMiner 0.42

The change log over 0.41:
- Improved speed on AMD GPUs:
Equihash 144/5: 
RX  580: 12.5 sol/s (0.41) → 22.5 sol/s (0.42)   (+80%)
Vega 56:  26.5 sol/s (0.41) → 33.5 sol/s (0.42)   (+26.5%)

Equihash 96/5:
RX 580: 11400 sol/s (0.41) → 12200 sol/s (0.42)   (+ 7%)

- Fixed a bug with SafeCoin (SAFE)
- Fixed a bug with the RIGNAME feature (it was not possible in 0.41 to make a user name without any worker name, that is fixed now)
- Added Asofe (ASF) compability (Equihash 144/5)

Download Links:
[Lin 64]: Click me (0.42 for Linux)
[Win 64]: Click me (0.42 for Windows)

And here are the virustotal reports for the two executables:
Linux: https://www.virustotal.com/file/209b18d40332ead62c5614d0edeb71451fbac2e6e92d47cb2e60448bbf4478b4/analysis/1534490309
Windows: https://www.virustotal.com/de/file/ba8ea8360dd0f0041fcde198299edf03b536b169cd5bdb4c89b079034c0852b0/analysis/1534490141

Hint: As you can see the Microsoft Windows defender detects the mining software as "PUA:Win32/CoinMiner " (Surprise ... its mining coins  ). So if you have trouble with it better replace the defender by any other anti virus (e.g. I use Avira AntiVir, which is also free) and you are fine.