Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v15.0 (Windows/Linux)

[blue1984]

I use Linux ubuntu 16.04 - with the latest driver. the last weeks works everythink fine... now i get only 18. MHS per card (before 27.5) AMD 470

What is the problem? BIOS? DAG?

[1714771078]

1714771078

[1714771078]

1714771078

[Claymore]

Hi Claymore,

To disable dual mining on some cards,
use -mode 1-[card index]
is there a way to disable dual mining on card index >9?use abced?

Yes, letters must work exactly as for "-di". From readme:

-mode   Select mining mode:
   "-mode 0" (default) means dual Ethereum + Decred/Siacoin/Lbry mining mode.
   "-mode 1" means Ethereum-only mining mode. You can set this mode for every card individually, for example, "-mode 1-02" will set mode "1" for first and third GPUs (#0 and #2).
   For systems with more than 10 GPUs: use letters to specify indexes more than 9, for example, "a" means index 10, "b" means index 11, etc.

[blue1984]

hy claymore is the DAG FIX on Linux only the DAG 160? is it possible to get 27,5 mhs (Rx470) with linux? i only get <20 mhs (after DAG 160)

lg

[valev1]

Hi Claymore,

I've received a few reports from users running Awesome Miner to monitor Claymore Ethereum miner about issues with larger number of GPU's. In some systems when you have a large number of GPU's, you get a timeout on the Claymore monitoring API - it simply doesn't respond within a reasonable time. If the user is starting the mining process with a few GPU's less, then it works fine again. So when you go above a certain number of GPUs, the monitoring API isn't working even if the mining itself is running fine.

Is this a know issue? Are there any workarounds?

Thanks!

Please send me some logs so I can check the reason.
...
Ok I see big delays now. What CPU do you have? What average CPU load in Task Manager?

No more PM, so I write here, after sending logs,
CPU model: Celeron G3930
CPU LOAD: 53%-56% normaly taken by EthDcrMiner64.exe, everything else is up to  5%
MB: ASRock H110 Pro BTC+
RAM: 4gb ddr4

no change with new version ( with high priority ), I tryed and with other CPU act the same way when 12 cards
if possible send me e-mail to write you there

[AzzAz]

Maybe someone has a clue about this problem I'm experiencing?

P.S. I've reinstalled the latest version of Win10 x64 downloaded from Microsoft and installed almost nothing. The AMD driver is the Blockchain driver from AMD's website. I use OverdrivenTool to write GPU registers since reinstalling Win10. Before reinstallation I used Wattman.

Try latest drivers ( or earlier windows with Blockchain drivers )

[Claymore]

Hi Claymore,

I've received a few reports from users running Awesome Miner to monitor Claymore Ethereum miner about issues with larger number of GPU's. In some systems when you have a large number of GPU's, you get a timeout on the Claymore monitoring API - it simply doesn't respond within a reasonable time. If the user is starting the mining process with a few GPU's less, then it works fine again. So when you go above a certain number of GPUs, the monitoring API isn't working even if the mining itself is running fine.

Is this a know issue? Are there any workarounds?

Thanks!

Please send me some logs so I can check the reason.
...
Ok I see big delays now. What CPU do you have? What average CPU load in Task Manager?

No more PM, so I write here, after sending logs,
CPU model: Celeron G3930
CPU LOAD: 53%-56% normaly taken by EthDcrMiner64.exe, everything else is up to  5%
MB: ASRock H110 Pro BTC+
RAM: 4gb ddr4

no change with new version ( with high priority ), I tryed and with other CPU act the same way when 12 cards

What CPU did you try?
Try to specify "-tt 0" option to disable temperature control, does it help?

[revelacaogr]

Satori Malware Variant is Robbing ETH BitCoin by Replacing Wallet Address - Claymore Miner Compromised, Check your settings

Art of Steal: Satori Variant is Robbing ETH BitCoin by Replacing Wallet Address
17 JANUARY 2018 on Botnet, BitCoin, ETH BitCoin, Satori
The security community was moving very fast to take actions and sinkhole the Satori botnet C2 after our December 5 blog. The spread of this new botnet has been temporarily halted, but the threat still remains.

Starting from 2018-01-08 10:42:06 GMT+8, we noticed that one Satori’s successor variant (we name it Satori.Coin.Robber) started to reestablish the entire botnet on ports 37215 and 52869.

What really stands out is something we had never seen before, this new variant actually hacks into various mining hosts on the internet (mostly windows devices) via their management port 3333 that runs Claymore Miner software, and replaces the wallet address on the hosts with its own wallet address.

From the most recently pay record till 2018-01-16 17:00 GMT+8, we can see:

Satori.Coin.Robber is actively mining, with lastest update 5 minutes ago.
Satori.Coin.Robber owns an average calculation power of 1606 MH/s for the last 2 days; the account has accumulated 0.1733 ETH coins over the past 24 hours
Satori.Coin.Robber has already got the first ETH coin paid at 14:00 on January 11, 2017, with another 0.76 coin in the balance
Also worth mentioning is that the author of Satori.Coin.Robber claims his current code is not malicious and leaves an email address(see the section below for more details):

Satori dev here, dont be alarmed about this bot it does not currently have any malicious packeting purposes move along. I can be contacted at curtain@riseup.net 
A Series of Security Issues on Claymore Miner Remote Management
Claymore Miner is a popular coin-mining software used by quite a lot of mining devices these days.

According to its document, the Claymore Miner Windows version provides a remote monitoring and/or management interface on port 3333 (the EthMan.exe file in the “remote management” directory). And by default earlier versions allow not only remote reading for mining status, but also operations like restart, upload files and some other control operations.

Apparently, the above feature is a security issue. As a fix, after version 8.1, the Claymore Miner will not use port 3333 but -3333 (a negative one) as the startup parameter by default, which means read-only monitoring actions are supported, but other controlling actions are all denied.

But this is not the end. In November 2017, CVE-2017-16929 went public, which allows remote read and/or write to arbitrary files for Claymore Miner. The corresponding exploit code has also been disclosed.

The scanning payload (the exploit code) we are going to discuss here is different from all above though. It works primarily on the Claymore Mining equipment that allows management actions on 3333 ports with no password authentication enabled (which is the default config). In order to prevent potential abuse, we will not discuss too much details in this article..............

[blue1984]

Hello,
is it possible to get 27,5 mhs (Rx470) with linux? i only get <20 mhs (after DAG 160)

lg

[Claymore]

1. CVE-2017-16929 works only if you specified -mport > 0 and don't use password (-mpsw). Also it can crash miner:

From History.txt:

...
v10.2
- fixed critical issues in remote management feature (attacker could crash miner even in read-only mode).
...

That was the last known security issue and it was fixed in v10.2 and above.

Here is my opinon:
Yes my miners have "remote management" feature that allows administrators to upload files, restart miners etc. It's not a vulnerability itself. Also I know that this feature can be used by attackers, therefore by default miner uses "read-only" mode which ignores all commands except "miner_getstat1" (I mean recent versions of my miners, very old versions have no "read-only mode"). User must specify "-mport" option and positive port manually to enable potentially dangerous commands. Also I added "-mpsw" option that allows users to set a password for remote management. Also miner shows warning during startup if "read-only" mode is disabled and -mpsw is missed. Also I added necessary information to Readme file. And, of course, it's bad idea to make these ports public, they must be used in local network only, "-mport" option can expose the port to specified network interface only.
To make this feature dangerous, user must do the following:
1. Disable "read-mode", ignore miner warning.
2. Ignore "-mpsw", i.e. don't set a password, again ignore miner warning.
3. Expose the port(s) to internet.
So, in my opinion, I did everything to make this feature safe as much as possible, but some users have no idea/knowledge what they do when they change default settings.

[revelacaogr]

1. CVE-2017-16929 works only if you specified -mport > 0 and don't use password (-mpsw). Also it can crash miner:

From History.txt:

...
v10.2
- fixed critical issues in remote management feature (attacker could crash miner even in read-only mode).
...

That was the last known security issue and it was fixed in v10.2 and above.

Here is my opinon:
Yes my miners have "remote management" feature that allows administrators to upload files, restart miners etc. It's not a vulnerability itself. Also I know that this feature can be used by attackers, therefore by default miner uses "read-only" mode which ignores all commands except "miner_getstat1" (I mean recent versions of my miners, very old versions have no "read-only mode"). User must specify "-mport" option and positive port manually to enable potentially dangerous commands. Also I added "-mpsw" option that allows users to set a password for remote management. Also miner shows warning during startup if "read-only" mode is disabled and -mpsw is missed. Also I added necessary information to Readme file. And, of course, it's bad idea to make these ports public, they must be used in local network only, "-mport" option can expose the port to specified network interface only.
To make this feature dangerous, user must do the following:
1. Disable "read-mode", ignore miner warning.
2. Ignore "-mpsw", i.e. don't set a password, again ignore miner warning.
3. Expose the port(s) to internet.
So, in my opinion, I did everything to make this feature safe as much as possible, but some users have no idea/knowledge what they do when they change default settings.

Thank for  the reply....
Well done

[RedDieselX]

i take it the latest amd drivers have yet again stopped claymore / afterburner from looking at or adjusting the fans ect?
i love the way amd forces their crap on us grrrrrrr

[miningguyno3]

Hi Guys.

I am really desperate. Ive been trying to set up my mining rig for 7days + now and i just can't get it stable, no matter what i try.

Hard ware:
- 6x rx580 8gb red devil hynix memory
  tried anoraknophobias bios & frosty s bios
- 1x rx580 8gb red devil samsung memory
   anoraknophobia bios
- msi z170a gaming pro carbon motherboard:
  newest bios
  above 4g encoding enabled
  pice max link speed gen2
  pice latency auto
  display output by integrated graphics by default
  windows whql enabled
- 60 gb ssd
- Intel Celeron Processor G3900 (2,80 GHz, 2 MB Intel Smart-Cache)
- 8gb RAM
- 2x 800w be quiet PSU (one for mobo + 3 cards, other for 4 cards)
- windows 10 home version 1703, build 15066.786
- aug. 23rd blockchain drivers
- claymore miner version 10.0
- virtual memory 30400mb

i have tried claymore settings:
-1100 cvddc -1100mvddc -1100 cclock -2100 mclock
to
-850 cvddc -850 mvddc -1250 cclock -2250 mclock

and pretty much anything in between in claymore v10.0 and v10.5, within 10 minutes max i get the infamous "GPU X hangs in OpenCL call, exit.." Error on one card after the other.

whenever i start the miner without any clock and voltage settings, the cards also ramp up to 30mhs, but fail within 10 minutes, same OpenCL error.

I have tried to troubleshoot:
- temperature is not an issue, all temps stay within 50-70 °C
- power doesn't seem to be an issue, i have added another 600w PSU to power one card of each of the other PSUs, didn't help
- i have fiddled with the pcie max link speed settings(gen1, gen2)
- i have swapped all risers
- CPU is not getting to too hot, although under heavy load during DAG creation & weirdly sometimes when one card fails or when i exit the miner
- I have tried the method of adding one GPU, testing it with the miner, adding another and so forth:
  inexpliccably, the rig seems to run fine with up to 3 GPUS, when i add a 4th GPU, the 3rd GPU starts failing. (not the newly added one).
- i have reinstalled windows several times
- tried to add claymore options -gser, -eres

The only thing i can think of is that maybe the CPU could be a bottleneck, since its under heavy load sometimes and can make the rig a bit slow for about 10 seconds. Still, the errors arise when the CPU is just sitting at 15ish %.


Another weird thing is that, whenever i let each card run individually, they all run fine with no issues for more than one hour. So i guess it cant be a riser issue.

But here comes the worst part:
I have set up another rig with 7x rx580 sapphire nitro+ 8gb hynix (anorak bios), same motherboard, same CPU, same amount of RAM same driver, same virtual memory, same version of Windows, claymore v10.0 and it happily runs on 850cvddc 850mvddc 1250cclock 2250mclock churning out a little over 200mhs for the past 3 weeks without any problems.

Its driving me nuts, seriously  

Please guys, if you have any idea what i could look for to get this baby stable it would be much appreciated.












  

[polymer_city2]

miningguy

This happened to me same build.

I had to build 4 rigs at the same time.

1st one, 30mins build to start mining - EASY (using some risers I got 6months ago)

Next 3 rigs took me 2 weeks!

I bought 30 new risers and 28/30 were duds!

So got some branded ones from China, plugged them in, all working no issues!

Quality of risers has deteriorated massively.

[Lamsterpaul]

How I can find out, witch riser are fine ?

[miningguyno3]

miningguy

This happened to me same build.

I had to build 4 rigs at the same time.

1st one, 30mins build to start mining - EASY (using some risers I got 6months ago)

Next 3 rigs took me 2 weeks!

I bought 30 new risers and 28/30 were duds!

So got some branded ones from China, plugged them in, all working no issues!

Quality of risers has deteriorated massively.

Which Brand did you get? Were you able to mine at all with the faulty ones?

[bond007taz]

1. CVE-2017-16929 works only if you specified -mport > 0 and don't use password (-mpsw). Also it can crash miner:

From History.txt:

...
v10.2
- fixed critical issues in remote management feature (attacker could crash miner even in read-only mode).
...

That was the last known security issue and it was fixed in v10.2 and above.

Here is my opinon:
Yes my miners have "remote management" feature that allows administrators to upload files, restart miners etc. It's not a vulnerability itself. Also I know that this feature can be used by attackers, therefore by default miner uses "read-only" mode which ignores all commands except "miner_getstat1" (I mean recent versions of my miners, very old versions have no "read-only mode"). User must specify "-mport" option and positive port manually to enable potentially dangerous commands. Also I added "-mpsw" option that allows users to set a password for remote management. Also miner shows warning during startup if "read-only" mode is disabled and -mpsw is missed. Also I added necessary information to Readme file. And, of course, it's bad idea to make these ports public, they must be used in local network only, "-mport" option can expose the port to specified network interface only.
To make this feature dangerous, user must do the following:
1. Disable "read-mode", ignore miner warning.
2. Ignore "-mpsw", i.e. don't set a password, again ignore miner warning.
3. Expose the port(s) to internet.
So, in my opinion, I did everything to make this feature safe as much as possible, but some users have no idea/knowledge what they do when they change default settings.

is the  "remote management" set to read-only on all versions  or version x.xx and later? I just want to check to see if i need to upgrade to latest ASAP

[jstefanop]

i have tried claymore settings:
-1100 cvddc -1100mvddc -1100 cclock -2100 mclock
to
-850 cvddc -850 mvddc -1250 cclock -2250 mclock



Please guys, if you have any idea what i could look for to get this baby stable it would be much appreciated.

If you think you will have a stable rig with modified timing and over 2000 mclock that will never happen. Start at like 1900 mem clock and move up until you find whats stable.

[xeridea]

Hi Guys.

I am really desperate. Ive been trying to set up my mining rig for 7days + now and i just can't get it stable, no matter what i try.

Hard ware:
- 6x rx580 8gb red devil hynix memory
  tried anoraknophobias bios & frosty s bios
- 1x rx580 8gb red devil samsung memory
   anoraknophobia bios
- msi z170a gaming pro carbon motherboard:
  newest bios
  above 4g encoding enabled
  pice max link speed gen2
  pice latency auto
  display output by integrated graphics by default
  windows whql enabled
- 60 gb ssd
- Intel Celeron Processor G3900 (2,80 GHz, 2 MB Intel Smart-Cache)
- 8gb RAM
- 2x 800w be quiet PSU (one for mobo + 3 cards, other for 4 cards)
- windows 10 home version 1703, build 15066.786
- aug. 23rd blockchain drivers
- claymore miner version 10.0
- virtual memory 30400mb

i have tried claymore settings:
-1100 cvddc -1100mvddc -1100 cclock -2100 mclock
to
-850 cvddc -850 mvddc -1250 cclock -2250 mclock

and pretty much anything in between in claymore v10.0 and v10.5, within 10 minutes max i get the infamous "GPU X hangs in OpenCL call, exit.." Error on one card after the other.

whenever i start the miner without any clock and voltage settings, the cards also ramp up to 30mhs, but fail within 10 minutes, same OpenCL error.

I have tried to troubleshoot:
- temperature is not an issue, all temps stay within 50-70 °C
- power doesn't seem to be an issue, i have added another 600w PSU to power one card of each of the other PSUs, didn't help
- i have fiddled with the pcie max link speed settings(gen1, gen2)
- i have swapped all risers
- CPU is not getting to too hot, although under heavy load during DAG creation & weirdly sometimes when one card fails or when i exit the miner
- I have tried the method of adding one GPU, testing it with the miner, adding another and so forth:
  inexpliccably, the rig seems to run fine with up to 3 GPUS, when i add a 4th GPU, the 3rd GPU starts failing. (not the newly added one).
- i have reinstalled windows several times
- tried to add claymore options -gser, -eres

The only thing i can think of is that maybe the CPU could be a bottleneck, since its under heavy load sometimes and can make the rig a bit slow for about 10 seconds. Still, the errors arise when the CPU is just sitting at 15ish %.


Another weird thing is that, whenever i let each card run individually, they all run fine with no issues for more than one hour. So i guess it cant be a riser issue.

But here comes the worst part:
I have set up another rig with 7x rx580 sapphire nitro+ 8gb hynix (anorak bios), same motherboard, same CPU, same amount of RAM same driver, same virtual memory, same version of Windows, claymore v10.0 and it happily runs on 850cvddc 850mvddc 1250cclock 2250mclock churning out a little over 200mhs for the past 3 weeks without any problems.

Its driving me nuts, seriously  

Please guys, if you have any idea what i could look for to get this baby stable it would be much appreciated.

Install HwInfo64. Check for memory errors and PCI link errors. Can also show as high system interrupts for corrected errors in Task Manager, and Windows Event Viewer.   I have issues with with some boards, recently Biostar TB250 having PCIE issues.  One I had to disable miner mode, only runs 4 cards anyway. Another I had to just replace board, would get PCIE link errors and restart dozens of times per day. I gave up on your motherboard a while ago because they seemed to not work with the Blockchain Drivers. I was using Aug 11 drivers so maybe the Aug 23 ones work?  Had issues on 2 of about 15 Biostar TB250s. My favorite board is Asus Prime Z-270A, never had an issue, does 8 cards, also 270P version does 7. Good mining mobos high price now though.

Until figured out, I would leave memory @ 2000MHz

[xeridea]

i have tried claymore settings:
-1100 cvddc -1100mvddc -1100 cclock -2100 mclock
to
-850 cvddc -850 mvddc -1250 cclock -2250 mclock



Please guys, if you have any idea what i could look for to get this baby stable it would be much appreciated.

If you think you will have a stable rig with modified timing and over 2000 mclock that will never happen. Start at like 1900 mem clock and move up until you find whats stable.

I run Ubermix straps for samsung mem, 2000 seems to be about stable limit, some I lower slighly.
I use custom Elpida strap, 1750MHz cards easily run about 2020MHz XMR miner all day long.
I using a custom Hynix strap, on 1750MHz cards, seems stable at least to 1970MHz XMR, testing in steps.

In my experience, Ethash algorithm requires a bit lower (20-40MHz) lower clock than CryptoNight. I don't know how people supposedly run stable above 2050 though with good straps.

[LMetz]

I'm having a big problem that I cant solve!
1 rig with 6 GPUs and simplemining cant set clocks. stay in 300/300 and mines 4mhs.
No matter if I put something in overclocking table, the clocks stay in 300/300
There is this error before it starts mining:
AMD ADL library not found.

Can this be the problem? How can I solve it?

Thanks!

Hardware:
Asus B250 Mining Expert
4Gb ram
1x rx480 8gb G1
5x rx580 8gb asus ocdual