The miner needs a lot of (virtual) memory on startup for AMD, what is a driver issue. More Precisely the AMD graphic driver in Windows starts to allocate the same memory in system Ram as needed by the GPU in the beginning, which is 2.9G at the moment. So if your rig has 8G of Ram you can max start AMD 3 GPUs.

That said what could work for you:
A) Start the miner on first 3 GPUs and wait / monitor in task browser until the mem consumption went down (which it slowly does over time)
B) Set your Windows swap (page ) file to a large fixed size, i.e. 36G, so the system thinks it has enough virtual memory. Some ethereum miners had that problem, too, so there are some good instructions around how to do that.

As for rig1:

To run it on Nvidia test out the "PLATFORM" parameter in the config file. Allowed entries are: "PLATFORM":"AUTO" and "PLATFORM":<anyNumber>.
In the 2nd case see that there are no parentesis. Wjen it is "AUTO" the miner will select the driver with the most GPUs in your system. When its a number N it will run on the Nth found OpenCL driver in your system, so you can use that to switch between AMD and Nvidia (note: there can be also Intel drivers out there, so can be that you have to test numbers 0 to 2.)

As for rig 2: can you open command line, go to lolMiner directiory and run lolMiner-144.exe -benchmark=BTG? Then it will try to do a BTG test run on your system. If it failes you can then see the error message without the script restarting the miner infinitely often.

Some pools unfortunately send an accepted : true message although they rejected a share.
What you can try is suprnova pool - as far as I know that one is accurate in its response message.

Still it seems that R280 and HD7000 cards produse invalid shares. Thats not good and I do not know yet why, investigating it currently.
What confuses me is that the kernels were all build from same source and same driver but some do valid and some invalid result what is confusing as the code os very deterministic. (At least long as you set the "COIN" : "XYZ" section right the code should work... hmm)

I will try to find a better way to give kernels to you...


Hu... the order changes? Thats odd. Will look into this. 100 is a bit too high - I assume some binary kernel problem again.
Its a pitty that there is no good IL for AMD kernels... hnmm

Hi there, may you share what driver you use? I will try to check why that one produces fault shares with the kernel


Single low diff shares can occur , but should be minority. If all are low diff shares some part of the miner does not work properly with your driver.


At all who have trouble with invalid shares:
Please share OS & Driver version. It seems my binary Kernels cause Problems on other then the blockchain drivers (whete they were compiled)


By the way: did anyone test with Nvidia how close to ewbf we are?

Well the thing is that AMD's intermediate language is hard to generate at the moment, so these kernels are pure binary kernels produced with certain drivers. Usually the kernels also work with other driver versions for that they were build for, but that can not be guarantied. 17.40 blockchain driver is mentioned pretty often here because that was the one I build and tested the kernel files with Other drivers may also work, but as said without any warranty.

Ok, here a new set of kernels:

Vega (gfx901):  https://drive.google.com/open?id=1nYLvfEZYQvhgCE-PHe_pZtnW34WHU6Zy
RX 550 (gfx 804):   https://drive.google.com/open?id=1N1sBrA26Cq7zHUhbuRDpzidSOkoigyn1
Tahiti (for completeness): https://drive.google.com/open?id=1pN-zUv3pvJvrsETFbQ-8j_3gxercIObV


----

The two kernels gfx901 and gfx804 were compiled on Windows with Blockchain drivers 17.40. Unfortunately the driver did not allow to build a kernel for gfx900, but in theory the one for gfx901 could work. Can one of the 900 users try to load the 901 and rename it?

On the friends vega 56 rig with the posted binary we got:
with about 900W power draw (whole rig at the wall)



Well I do not do this as hobby - I have registered that as business and pay my taxes - but these coins at are quite small and there are very good cuda miners, so what I get from this is rather small at the moment (although my miner is not (much) slower for Nvidia then competitors ^^). So for the start I need the 2%, but I will lower it. Promised and till now I always remembered my promises here

Hmm it could be the driver version. I did compile the binary kernels with pretty young drivers and AMD does not guaranty for compatibility between versions - so it just could be that the 15.12 are too old for the 17.40 compiles binaries.


The option is there ... in the config file you can replace "DEVICE" : "AUTO" by "DEVICE" : [1,2,3] to only run on your 2nd, 3rd and 4th card. The first one of yours seems to have an issue. 71 sol/s would be nice, but its definitely too much to be a correct result.

Damn you are right ^^ Well you see some stuff written / released here with a hot needle. Well ... thats why its a preview ^^



Can you be a bit more specific? What I could need get things better: GPU and driver version and - if you see some - the error message the miner prints out to command line



Vega currently seems broken, working on a solution.


I will start tuning for AMD asap - right now lets sort out the AMD driver troubles

I was not aware of AMD 3G GPUs ... well ... they could work, just not tested it ^^
I just got news that AMD GCN 1 Tahiti cards generally work, just put this file https://drive.google.com/open?id=1pN-zUv3pvJvrsETFbQ-8j_3gxercIObV into same directory as the other ones


That bug is stange ... but had that error message before with other Windows build kernels as well ... hmm ... you can try using the Vega kernel included in the Linux package (it is different) ... if that is still not working I will try to call back my testers so I can compile a vega kernel on one of their systems.

Hi folks,
this is the announcement thread for lolMiner-144.5 v0.38 public preview.

So what is this miner good for: at the moment it mines Equihash 144.5 (BTG, BTCZ, LitecoinZ, Safecoin, Snowgem) OpenCL based, so for Nvidia and AMD.

Why it is a preview? Well the miner is kind of a successor to my Minexcoin (MNX) miner you can find here. The final version is supposed to be wider configureable as it is now, bring an API and add the Minexcoin miner (and others) as well.

If you do not want to read much more long descriptions, here are the download links:
[Lin 64] Klick me (0.38 Preview for Linux)
[Win 64]   Klick me (0.38 Preview for Windows)

-----
Edit: For those with problems, here additional / extra compiled kernels:

Vega (gfx901):  https://drive.google.com/open?id=1nYLvfEZYQvhgCE-PHe_pZtnW34WHU6Zy
RX 550 (gfx 804):   https://drive.google.com/open?id=1N1sBrA26Cq7zHUhbuRDpzidSOkoigyn1
Tahiti (for completeness): https://drive.google.com/open?id=1pN-zUv3pvJvrsETFbQ-8j_3gxercIObV

The two kernels gfx901 and gfx804 were compiled on Windows with Blockchain drivers 17.40. Unfortunately the driver did not allow to build a kernel for gfx900, but in theory the one for gfx901 could work. Can one of the 900 users try to load the 901 and rename it?

-----

Compatibility:

Nvidia:

For Nvidia the miner runs on any Maxwell and newer generation GPU with at least 3G of RAM and CUDA 8 or newer installed. That said there is a restriction: due to some driver specific hard codings it does not work in Windows with 3/4G Nvidia cards while on Linux that is no problem when the cards are in compute mode. I will work on resolving the Windows issue soon.

AMD:

For AMD we require any 4G / 8G GCN2 and newer GPU, so Hawaii (R9 290 / 390), Tonga (R9 285 / 380), Fiji (R9 Fury series), Baffin (RX 460 / 560), Ellesmere (470, 480, 570 and 580) and Vega series GPU. Most kernels (exceptions below) are build with the 17.40 blockchain driver.

For Vega: The Windows kernel for Vega is build with a very new AMD driver version (Adrenalin version 18.5.1). It is unknown if older drivers then this are supported. For Linux the AMD Vega kernel is only available for the AMD ROCM-CL driver! I have to admit that we did not test Vega GPUs yet, so crossing fingers it will work. Else I will try get it working asap.

Setup:

There is a quickstart guide shipped with the miner. Read that carefully and it should work. Else feel free to ask here

Estimated speed:
The miner just got finished, so we have no broad basis yet.
But approximately:

GTX 1080:   ~36 sol/s
RX 560:   ~7 sol/s   
RX 580:  ~13 sol/s
R9 290:  ~12 sol/s

All depend on OC settings of cause

F.A.Q. and known Issues:

The AMD miner is slow…
Well, I know that. I was struggling get this working, so tuning is now next, see schedule below.

Miner hangs on 0 sol/s (AMD)…
When the GPU does not complete its work and hangs a GPU the miner will try to close itself as soon as possible for restart. On Nvidia this works very well, but on AMD the driver timeout is 1 hour, so this takes a pretty long time. Lowering OC settings usually makes this evens much more rare.

The Windows miner crashes…
… from time to time. This is because the Windows version is a cross build with pretty old runtimes. This will be resolved soon (hopefully). In the meantime head out for a Windows watchdog I will provide next days that mitigates the problem.

My coin with Equihash 144.5 is missing...
Oh, sry, maybe I just was not aware of this. Drop me a note here with the required details and I will add is very quickly. This is a rather quick action

How much is the fee?
I used to start with an 2% fee like for my MNX miner. That said I lower the fee once payed of my expenses and time to develop stuff. For example for Minexcoin I lowered the fee to 1.5% after a month and next release will be even lowered to 1%. Expect similar here.

Does the miner disconnect for fee?
No, I has two connections open all of the time and does every x iterations one iteration for me. That way the mining income remains smooth. Also the displayed sol/s are net with fee already calculated out, so what you see is what you get.

What comes next?
I will try to build a bit more efficient AMD kernels within the next week. Then from the things recently learned I will do a mayor code change for AMD to improve performance further. Furthermore I think in about 2 weeks I will add Zero (Equihash 192.7) to the miner.
Finally in about a month there should be 0.4 with the promised MNX integration and a simple API *crossing fingers*.

Why JSON for configuration? Why? Whyyyyy?
Huuusshhh. Just be careful with setting ',' and all will be good. When used to it, it is a very need way to configure the miner, you will see.

That version number is strange...
Well the next release version for my MinexCoin miner is supposed to be 0.4 and the development versions go along with internal feature level... so this is mainly for myself to keep track

Well 1060 3G and 6G versions also differ by the number of shader clusters (9 vs 10), so overall you can expect the 6G gives approx 10% better hash rate. Else the 3G is not limited (in this algorithm), so the more memory on 6G itself is not of an advantage.

Eta is about a month from now - atm with all the algo forks in Equihash land this are bussy times for mining software developers, but it will come

Recently released a Equihash 192.7 miner preview (atm Nvidia only) and currenrly try to make a fast 144.5 including AMD versions and making the 192.7 faster.

Hi folks,

well you may have heard the rumors and it is true: there is a new software for mining zero: lolMiner-zero.
And yes, it can run on 3G GPUs

The development of this is in a very early phase, but never the less I wanted to provide you a preview version, here are the links:

Linux 64: Klick Me (Preview Version 0.37, Linux)
Windows 64: Klick Me (Preview Version 0.37, Windows)
Note: I was not able to test the Windows package due to the lack of a GPU with more then 3G .. plz report any problems )


In both packages you will find a detailed manual as well as quick start guide in 4 simple steps. Should not be to hard to get it working.

Here are some „FAQ style hints“:


With what GPUs is lolMiner-zero compatible?

At the moment the preview version is compatible to all Nvidia GPUs of the Maxwell generation and newer with at least 3GB of RAM.
To run the miner on 3G cards I would recommend doing that headless or with an other GPU as graphics adapter, especially on Windows.


How many sol/s can be expected from lolMiner-zero?

We have not tested all cards, but we know of:

GTX1060 3G: 8.75 sol/s
GTX1060 6G: 9.5 sol/s
GTX1070: 13.5-14.5 sol/s
GTX1080: 18-20 sol/s
GTX1080 Ti:  23-25 sol/s

Is there a fee?

At the moment there is a 2% fee that will be lowered later (once main development costs are covered). The displayed sol/s is net, so the 2% is already subtracted and you see what you get.


Are there known bugs?

All versions:
From time to time a GPU gets stucked and reports 0 sol/s. In this case the miner will stop mining, but the scripts shipped with the miner can restart it. This happens more often when the memory overclock of the GPU is high or when too many GPUs are used in same miner instance.

Windows:
The windows runtimes are a bit buggy and can lead to crashes. The provided watchdog is able to detect those failures and restart the miner properly.



As said: it is beta and this is even a preview. The full version will come in few weeks and also feature AMD compability, more stability and features. Stay tuned!

The random crashes during run on Windows are due to instable runtimes. I will try to improve that on next version.

On startup the reason could be different, e.g. missing OpenCL drivers. Did you try to run "clinfo" to see if your GPUs are properly recognized by OpenCL?

The miner is OpenCL ... just load it from the links from the start page.
MxMiner, originally from Racquemis, is about more then a magnitude slower then this one here on Nvidia devices. For 6 GPU just run the miner - it should find them when your OpenCL driver is installed and finally the fee is 1.5% atm as described in first post and readme file.

I would like to add some aspects to the anti asic and protection against 51% attack discussion.

More concretely I would like to address the questions:

Is is the upcoming fork the reason for the attack?
In my opinion unlikely but may be. I think the fork and bitmain could be kind of a catalyst.

Was the attack possible because a fork did not take place long time ago?
Yes, definitely!

Why do I think so:
An attack is nothing that happens spontaneously. When you want to attack a network with a double spend attack you have to accumulate the currency before and not too many people noticing it. Also must ensure you got a manipulated node that builds its own chain and so on. This is nothing you do in few minutes, it requires knowledge and preparation. What I meant is: it may be that this as well as the past BTG attack was planned for a long time. Therefore I do not think it was a direct reaction to bitmain or the upcoming fork but it may be that the fork did determine the time point for the attack because once the fork happened the vulnerability is gone or mitigated.

Why that? Well the vulnerability is that the ratio of potential hash rate for the network over the actual net hash is too high. Zcash is the largest coin with Equihash 200.9 and has more then 10 times the net hash rate of ZEN. So it is natural that 10 to 15% of Zcash net hash are avail for rent just on one provider. While this is no problem for the big fish Zcash itself it is one for every small coin that uses the same algorithm. 51% Attack is available for rent! And it will be as long as Zen is not the largest coin of those sharing its algorithm.

Therefore the Zen team should have reacted long time ago - maybe when starting the coin - by forking to another algorithm - one that is unique for Zen! IMAO that is the only way to get rid of such attacks because as long as we stay on this it can happen again and it will happen again if the ratio between the price for doing the attack and the outcome for the attackers is positive. So either they bomb Zen price down to 1$ or the netHash increases high enough that the avail Equi 200.9 hash rate is no problem - then it will also not be one when the ASICS come.

More easy would be a fork to another algorithm. But please: be creative! Why do most now forking coins announce they want to use 144.5? When all do, then still the Zen network hash may be a problem for BTG or BTCP or others. Just the same on a different scale. Why not be more creative and do something unique for the coin? 192.7 has similar requirements regarding memory but already used by a small coin called Zero. Hmm .. but in between 168.6 could be an option.

Or why not pick something that also prevents large mining farms to be build for mining. Already 144.5 causes problems for GPUs with 2G of ram. 150.5 would almost be not possible to mine with 4G GPUs, 156.5 would rule out 8G cards. Going to  162.5 or 168.5 would mean that - except for extremely expensive server GPUs like Tesla V100 32G -  there are no GPUs with large enough memory to mine the coin. The only way to do it is on CPU in RAM (making large farms expensive) or swapping memory from GPU to host computer during the computation to ensure enough memory is on the card to continue. The latter would require GPUs to be connected by fast PCIE connector (so no riser) and to have enough swap space on the system to put the data there.

Of cause that also may rule out many private miners, but in fact it makes the coin non-profitable for huge data centers and huge mining farms that can easily swap their whole hash power quickly to wherever they like making it dangerous again.

So my conclusion: to prevent this happening again it is better to fork as soon as possible and please not to an algorithm already used by any coin with more value then  Zen. Doing this to protect the network from more attacks should be the main priority for the Zen team.

Well thats a Windiws specific problem that so many virtual mem is required on startup as is requested mem.on GPU.
As an alternative you can fix --set-work-batch to a lower value, e.g. 8
For Nvidia the performance hit is low, less then 5% but then the miner uses much less Memory also on startup

When you have installed the graphics driver (including OpenCL) its rather simple: open the example_config.cfg, put in your wallet name (and desired pool) right in the beginning and then start the run_miner.sh file from command line. Thats it



Hnm ... looking like a bug ... thats twice what I would expect from that card. Unlikely from the available memory management the card can get so fast. But wonder how this happend...

Well I have to patch at least one bug I fixed in 0.2 into every 0.1x version I release here again since that bug may cause znomp pools to crash...

So - unless you give me very good reason why you need that I would prefer not to release this old versions again. As far as I know the newer perform better and are much more stable, so I do not see the need for this.
(By the way: currently 85% of all MNX blocks are mined by lolMiner and of them approx 90% with 0.3x versions  )

Sry it may be my fault, because I am no native English speaker, but I do not really get your request. Can you rephrase your problem what exactly you need / looking for?