Sry for the long silence here, I was busy with coding

New version 1.56 is just released improving the performance on Flux a lot and bringing finally competitive Flux & Beam solvers for Nvidia Ampere GPUs
Hope you like the update

Please update your system
Glibc 2.25 is in Linux since March 17 - update your os and it will be fine

Sry for not writing here for a while. But now

Happy new year to all that are already in

We have a new release bringing some new algorithms (finally), here is the full change log:

Feature updates

• Added support for mining TON. Use --algo TON to mine it. Developer fee is 1.5%, AMD cards since GCN1 (via OpenCL) and Nvidia cards Maxwell and newer generation (via Cuda) are supported.
• Added support for mining Ubiq. Use --algo UBQHASH to mine it. The fee is 0.7% as with all Ethash based coins.
• Added support for routing your stratum traffic through a socks5 proxy server. Use --socks5 : to enable it. Note: at the moment this does not work with https traffic as in the TON algorithm. We will work on that.

Fixes

• Added a timeout for DOH requests, so they can no longer hang indefinitely.
• Fixed ethash support for RX 5500 series GPUs on more recent drivers.

Example files for the new additions are of course included into the download packages.

Well, that is easy - just read what the changes are about.
Last week many PoW networks saw a big loss in hashrate, because the China firewall started blocking dns resolition and mining traffic towards mining pools. This update handles exactly that messy situation by allowing to mine on behind the fw (use tls enabled and --dns-over-https 2). Because the update mainly addresses problems in China I tried to welcome them more by doing the change log in Chinese one single time

I just checked eu nicehash and there got no "real" single disconnect ...
But let me explain:

Nicehash on Ergo uses a command
to tell the miner that it shall reconnect. This happens when your hashrate is supposed to switch to an other buyer, because at the moment with Autolykos this is the only way to give a new extra nonce / to switch destination pool. That said there is a difference between trex and lolMiner: lolMiner at the moment is telling you connection got lost and it will reconnect in 1 second - while trex is silently doing it. Maybe lolMiner should be more precise with the message here, because it is not really a "lost" connection but instead a Nicehash requested reconnect that is needed to re-route your hashrate to the current most biding buyer.

So in fact if you see this message on Nicehash: everything is ok! But I will amend the messages printed and will remove the 1 second wait time for this case - I hope that will solve your uncertainty about it  

As a member of Beam Foundation ... lets try to clear some things


Sry for being skeptic here, but - can you give a single example about data collected by Beam team? If you create a desktop wallet you just run the software and the only data you need to insert is a password to protect your own wallet. Not more, no personal data collected. And as you can see in the source codes of Beam also for transactions there are no real metadata collected on top of what is needed to do the transaction. So please give examples for your claim. Note that stuff like KYC on exchange does not really count, cause every serious exchange needs to do that in case they want to allow trading with fiat currencies - and for Beam you even can trade to other crypto by just using the atomic swaps in the Wallet without giving any KYC data to anyone.


Well - do you know where all the other developers of other projects are sitting? I mean ... for Beam the Team is quite well known, there is a quite complete list on the website - and even with real names. It is easy to google them and find out where people are sitting. It is true, that the Beam "HQ" is located in Tel Aviv, but team overall coming from many countries - we got the UK, Belarus, Singapore, Germany and others in the list as well.


Ahm wait. Where is to promises to HODL? No, the Beam is not being hodl - well unless single individuals decide to do. If you analyze the file in github which does the tax-transactions you will see that there is not one big wallet getting it all. Instead the core developers wallets, investors wallets and also the foundation wallet are hard coded into the source code. Especially for the developers: that is their salary - they can hodl if they want, but are free to spend  when ever they like or need - e.g. to pay their daily expenses. I only can tell you about the foundation wallet though (getting 2.5% and so is the biggest single wallet). Here the situation is like "keeping some buffer" for unforeseen situations, but generally the money is spend. To fund stuff like hackatons, or ambassador events or ... well ... to fund overall we get an ecosystem for the Coin. It was never said the money will be hodl only - and to be honest that would be stupid! We need to develop an ecosystem to survive - as any crypto does. And that costs money. Also ... from side of an investor: would you like a currency where you do known one person holding a high % of the supply? That could drop a huge bomb every day? We rather aim for having the situation to say "well, that is it, funds are depleted, we are out" once the tax ends. Because then the funds are in circulation and no one needs to be afraid there could be a big drop later on. We are not XRP or stuff like that ^^

Any error message from them in the miner log? Usually the 3070 should be supported by the driver. Some appear not to mine, because defect entries in the DAG were recognized ... then the repair kicks in and taking a while to do its job.
 I need to improve the fix function further - I guess - to be quicker.

Sry for the long silence here, but well - jgonzi took over a lot of the support needed here.

But today want to announce something new - and kind of special:

lolMiner 1.29 brings a partial unlock for you RTX 3060 users!

Partial here means that it is not able to get the full 48 mh out of the card, but at least some good way up from the known barrier (approx 36 mh). And different from existing Windows solutions this here has some advantages:
- Risers are no issue
- No screen or fake hdmi needed
- No limitation on the number of GPUs
- It works in your favorite Linux mining OS

Only requirement it has: you need to run Nvidia Cuda drivers 455.45.01 to 460.39 - newer drivers have a changed lock mechanism and are not so easy to trick.
Have fun mining!

Well not an own discord server, but a channel within the red panda discord. Also I got an own telegram channel if you need quick / direct contact
Can you share your error message you have with the miner? On latest hive stable image it should be as easy as creating a lolMiner flight sheet and go. No extra options for the 4G cards urgently required. It still is recommended to add --4g-alloc-size parameter to the user arguments, which will improve performance. Check 4076 first. If miner starts check 4078 and then 4080, which is highest I know to be stable on most machines. 


Always welcome. I think its not unveiling anything when I say I am happy to do so, because well - when starting with Ethash I was kind of the underdog out there - and still my share is not huge, but large enough to be worth it by margin. Well and most of that is due to the zombie mode I will try to keep this 4G cards as long profitable as possible. Still need to be serious - we maybe got an other month. With cheap electricity or the GPU in a x8 or x16 slot maybe two month, but the things that can be done are limited time effects :/

Just wanted to tell you I just pushed the Linux build of lolMiner 1.18 
(The Windows one will follow within 24 hrs)

Here is the repo link

This time especially some more candy for my beloved zombie mode users:

Feature Updates:

•     Improved linux zombie mode power draw & speed Polaris GPUs (R9 380, RX Fury, RX 4x0 and RX 5x0). Depending on configuration, the zombie mode now uses 0.5 to 1W less energy and is 0.2 to 0.4 mh/s faster.
•     Added --zombie-tune parameter for Polaris GPUs. This will increase the performance of zombie mode (further up on the general improvement) by an other 5-15%, depending on parameter and epoch (later epochs profit more). Default value is 0 (off), for most cards the value of 2 is optimal. If you see cards getting slower then before, set to 0 or 1. Note: you either can give one value for the whole rig or provide a comma separated list for each card individually. Cards not running zombie mode ignore the parameter.
•     The parameter --4g-alloc-size can now also be set for each card individually
•     Slight rework of Beam Hash III back end. Improves poolside hash rate by approx 0.2 to 0.3% - displayed hashrate and power consume kept equal.
•     Added a 4G_Ethash_Linux_Readme.txt file to the Linux release, giving guidance how to configure for ideal zombie mode performance.

Fixes:

•     Segmentation fault when the dns resolve of a pool fails
•     Miner does not restart after connection loss.
•     Applied potential fix for "address or port already in use" bug.

Please read the new 4G_Ethash_Linux_Readme.txt carefully to know how to configure the miner for ideal zombie mode performance.

It understand --devices AMD and --devices Nvidia or alternatively you can use --devices 0,1,2,4 to skip e.g. 4th card (index 3) in the system.
So you can indeed open two miner windows where one is pointed to Ethash and one to Beam, both using just different devices strings.

In json the configuration is 100% same
"DEVICES" : "0,1,2",
will select first 3 cards,
"DEVICES" : "3,4,5",
will select the 2nd set.

Even though we are competitors and don't always agree, I can still confirm Zminer777's identity as one of GMiner's developers. The forum posts informing about new software updates are certainly not to be classified as spam or scam, as they still refer to the official GMiner repositories.

Well you can see the number by using a web browser. Calling http://<ip of rig>:<api port>
Then the numbers are at least visible from external

Just want you to know, that --keepfree 5 is not needed any more when 4G alloc size is set  - at least not in Linux, only for Windows it would make a difference (but Eth is pretty dead on Windows already)
The decrease to 93% of original speed is pretty normal here for epoch 383 kicking in, since 382 did fit perfectly to the memory, but 383 does no longer. Thats the fate with Zombie mode, it will decrease on every further epoch - at least on the 4G cards :/




No, pretty sure this is no driver crash. Rather something in pool communication that went wrong, because it did crash exactly the moment where it did submit a share and was waiting for pool response. I will compare the code to see if there is some bug in (but this should not be changed for 1.17 ... hmm ... anyways, I will double check it)

I tried this but it doesn't seem to work. I get error

I am glad that you brought this up because this is something one of my GPU needs because I had to manually disable it because during some times of the day it just overheats way past 80C.
[/quote]

Can you verify you run the latest release (1.17)? Because the earlier ones do not have the parameter, it was freshly introduced

I hope for the Windows version soon - though does not depend on me, but on the code signing authority. But in case it takes to long I will put an unsigned version online and re-upload with code signature once it is done.
Wrt your other question: yes, the new version can allow either all or one specific card to use only one mining thread, freeing some resources for other tasks. At least on my desktop it did help to be able to browse and play youtube while the first card was mining - then a bit slower, but it was working.
New parameter for it is --singlethread



Ah sorry... the issue is the 290 4G does not support Zombie mode at the moment. I would rather suggest mining etc with it Very sorry about this, but even if I start developing Zombie for it now ... well ... when I am finished it might be not worth to use it then :/


No worry, that will work The miner is just no longer spamming to the whole 0.0.0.0 range Or speaking differently: if you are in same local network you still should be able to connect your browser to your rigs, no worry.

Lets say hello to  lolMiner 1.17 (LINK)

Was some longer coding this time since the re-coding of Navi codes took some serious time.
But I like the result and hope to bring it to other cards as well in the future. We will see how it works out there

I wish you all a Merry Christmas and a good start into 2021.
Try to stay healthy!

Different to Claymore lolMiner has no setting of timings yet - while Claymore does change GPU settings. Likely you will be able to resolve the issue by applying a timing optimized bios to your cards. Or use amdmemtool to improve the settings via software.

Quick info for upcoming ETC hardfork (in few hours):

lolMiner 1.16 (and the versions before) is ready to support the fork that will happen on block 11 700 000.
To automatically switch over to the new scheme use --algo ETCHASH when you run the miner manually.

If you are using a mining OS like HiveOS, please select ETC or ETCHASH as parameter in your flight sheet.
In case you can not change it or are uncertain you alternatively can add --enable-ecip1099 to your extra user configuration parameters.

Note that ETCHASH = ETHASH + ECIP 1099, so the result will be the same and you can safely add  --enable-ecip1099 to any working configuration without damaging it.


All of this also applies when you mine ETC+ZIL! In this case just configure for ETC mining - the miner will recognize the ZIL mining and switch to ETHASH for that time and switch back to ETCHASH once Zil mining is over.
Have fun with the fork.



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




I answered about this one few pages earlier. Octupus is extremely compute heavy, in particular multiplication of two 32 bit numbers to a 64 bit one. While Turing and Ampere can do this operation using only one clock cycle, the AMDs need 4 (professional cards & Vii) to 8 clock cycles. Also Turning and Ampere can do easier operations in parallel. Therefore the expected performance on AMD is rather ... horrible. I did some tests but was way away from the two modern Nvidia numbers here. It might be that big navi can do better, but the full instruction set for this architecture is not yet released. Waiting for that if this allows some quicker approach.

Which driver version you are on and have you checked other values for --keepfree and --4G-alloc-size like described in the 4G_Windows_Readme.txt?



Well wrt SAM I am not sure yet what effects that has. On ethash you see the impact of the cache when building the DAG (way faster then on RX 5700 although bandwidth did not grow that much) and when mining ZIl, cause that uses a 1G dag that fits to over 12% into the cache - there the card is about 10% faster then for the 4G dag. For other algos I still try to understand how to use it ideally. Generally the card already is the fastest Equihash card among all AMDs (reaching 90+ sol/s on BTG) and its 2nd fastest on Beam. I got good hope to profit from the cache in Beam and Grin C32.