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

[bategojko74]

I know you can take a log file and if you have a long enough mining duration say 1 month, then you can easily add all the accepted+rejected+stale and get an accurate measurement and being within +- 1% is fairly close.

I think the 1% loss you are talking about is not related to the Claymore software but most likely due to the GPU drivers. I know with my AMD RX series GPUs there is a time when some GPUs hash a little slower for a few seconds and then resume the optimal speed. Been trying to figure out why it happens but couldn't and just left it the way it was because the speed loss was minimal. So find in your logs if your speed was always constant or did it slow down from time to time. You can probably find this easily with MS Excel when you load your log file.

Nobody is talking about speed fluctuations here. The averaged stated speed incorporates them. If miner does not work at some moment it prints 0.000 Mh/s in console (and log) and this zero is heaped when calculating the averaged speed and the number of samples is increased by one for this zero. Come on man use a little the last floor of your body. I talk that this averaged stated speed in console and in the log is 1.5% higher than the real one which can be calculated from the found shares (locally, not at the pools side), difficulty and the time that the miner has worked.

[1713574999]

1713574999

[1713574999]

1713574999

[1713574999]

1713574999

[1713574999]

1713574999

[1713574999]

1713574999

[Ursul0]

I know you can take a log file and if you have a long enough mining duration say 1 month, then you can easily add all the accepted+rejected+stale and get an accurate measurement and being within +- 1% is fairly close.

I think the 1% loss you are talking about is not related to the Claymore software but most likely due to the GPU drivers. I know with my AMD RX series GPUs there is a time when some GPUs hash a little slower for a few seconds and then resume the optimal speed. Been trying to figure out why it happens but couldn't and just left it the way it was because the speed loss was minimal. So find in your logs if your speed was always constant or did it slow down from time to time. You can probably find this easily with MS Excel when you load your log file.

Nobody is talking about speed fluctuations here. The averaged stated speed incorporates them. If miner does not work at some moment it prints 0.000 Mh/s in console (and log) and this zero is heaped when calculating the averaged speed and the number of samples is increased by one for this zero. Come on man use a little the last floor of your body. I talk that this averaged stated speed in console and in the log is 1.5% higher than the real one which can be calculated from the found shares (locally, not at the pools side), difficulty and the time that the miner has worked.

I'm trying to follow but it's a bit confusing. So now you are claiming that the speed that the miner displays in console and reports to the pool is 1.5% higher than the actual one? and is that somehow related to your previous claim of Claymore taking higher than advertised devfee?

[Ursul0]

Did anyone succeeded in improving 1060 hashrate with any of v15 tighter straps and what's the rate/GPU?

This how it's most stable on phoenix for me:


Using strap 2 I'm able to see them doing over 26MH, but hashrate jumps around and eventually stabilizes around the same level.

[bategojko74]

I know you can take a log file and if you have a long enough mining duration say 1 month, then you can easily add all the accepted+rejected+stale and get an accurate measurement and being within +- 1% is fairly close.

I think the 1% loss you are talking about is not related to the Claymore software but most likely due to the GPU drivers. I know with my AMD RX series GPUs there is a time when some GPUs hash a little slower for a few seconds and then resume the optimal speed. Been trying to figure out why it happens but couldn't and just left it the way it was because the speed loss was minimal. So find in your logs if your speed was always constant or did it slow down from time to time. You can probably find this easily with MS Excel when you load your log file.

Nobody is talking about speed fluctuations here. The averaged stated speed incorporates them. If miner does not work at some moment it prints 0.000 Mh/s in console (and log) and this zero is heaped when calculating the averaged speed and the number of samples is increased by one for this zero. Come on man use a little the last floor of your body. I talk that this averaged stated speed in console and in the log is 1.5% higher than the real one which can be calculated from the found shares (locally, not at the pools side), difficulty and the time that the miner has worked.

I'm trying to follow but it's a bit confusing. So now you are claiming that the speed that the miner displays in console and reports to the pool is 1.5% higher than the actual one? and is that somehow related to your previous claim of Claymore taking higher than advertised devfee?

I was wrong that Claymore is taking higher than the advertised devfee. But I am 1000% sure that Claymore shows and reports to pools (if he reports what he shows in console) about 1.5% higher hash rate than the real one.

[Ursul0]

I know you can take a log file and if you have a long enough mining duration say 1 month, then you can easily add all the accepted+rejected+stale and get an accurate measurement and being within +- 1% is fairly close.

I think the 1% loss you are talking about is not related to the Claymore software but most likely due to the GPU drivers. I know with my AMD RX series GPUs there is a time when some GPUs hash a little slower for a few seconds and then resume the optimal speed. Been trying to figure out why it happens but couldn't and just left it the way it was because the speed loss was minimal. So find in your logs if your speed was always constant or did it slow down from time to time. You can probably find this easily with MS Excel when you load your log file.

Nobody is talking about speed fluctuations here. The averaged stated speed incorporates them. If miner does not work at some moment it prints 0.000 Mh/s in console (and log) and this zero is heaped when calculating the averaged speed and the number of samples is increased by one for this zero. Come on man use a little the last floor of your body. I talk that this averaged stated speed in console and in the log is 1.5% higher than the real one which can be calculated from the found shares (locally, not at the pools side), difficulty and the time that the miner has worked.

I'm trying to follow but it's a bit confusing. So now you are claiming that the speed that the miner displays in console and reports to the pool is 1.5% higher than the actual one? and is that somehow related to your previous claim of Claymore taking higher than advertised devfee?

I was wrong that Claymore is taking higher than the advertised devfee. But I am 1000% sure that Claymore shows and reports to pools (if he reports what he shows in console) about 1.5% higher hash rate than the real one.

Ohh I see.
If you are into this kind of action can you maybe do all of us a favor and perform the same analysis on this one https://bitcointalk.org/index.php?topic=2647654.0
And maybe post here with numbers and such?
I know for myself I'd be very much interested to see the actual numbers. Thx.

[bategojko74]

I know you can take a log file and if you have a long enough mining duration say 1 month, then you can easily add all the accepted+rejected+stale and get an accurate measurement and being within +- 1% is fairly close.

I think the 1% loss you are talking about is not related to the Claymore software but most likely due to the GPU drivers. I know with my AMD RX series GPUs there is a time when some GPUs hash a little slower for a few seconds and then resume the optimal speed. Been trying to figure out why it happens but couldn't and just left it the way it was because the speed loss was minimal. So find in your logs if your speed was always constant or did it slow down from time to time. You can probably find this easily with MS Excel when you load your log file.

Nobody is talking about speed fluctuations here. The averaged stated speed incorporates them. If miner does not work at some moment it prints 0.000 Mh/s in console (and log) and this zero is heaped when calculating the averaged speed and the number of samples is increased by one for this zero. Come on man use a little the last floor of your body. I talk that this averaged stated speed in console and in the log is 1.5% higher than the real one which can be calculated from the found shares (locally, not at the pools side), difficulty and the time that the miner has worked.

I'm trying to follow but it's a bit confusing. So now you are claiming that the speed that the miner displays in console and reports to the pool is 1.5% higher than the actual one? and is that somehow related to your previous claim of Claymore taking higher than advertised devfee?

I was wrong that Claymore is taking higher than the advertised devfee. But I am 1000% sure that Claymore shows and reports to pools (if he reports what he shows in console) about 1.5% higher hash rate than the real one.

Ohh I see.
If you are into this kind of action can you maybe do all of us a favor and perform the same analysis on this one https://bitcointalk.org/index.php?topic=2647654.0
And maybe post here with numbers and such?
I know for myself I'd be very much interested to see the actual numbers. Thx.

Interesting idea. I will collect one week log with my rig and post you the logs with extracted sample hashrates that form the averaged stated hashrate and all the calculation results. Thanks for the idea Ursul0.

[micalith]

I am having internet connection issues while mining. I checked some articles and tried the solution they offered but they didn't seem to be working for me. I tried a different source of internet and still, it doesn't work. The problem is, when I start to mine with my GPU, in 10 minutes, I lost the wi-fi connection. The modem is close to me, I haven't get the chance to use a cable but I don't think it will work. What is causing these problems?

[Smoreno]

Hey Claymore

Cannot resolve 'eu1.ethermine.org'
ETH: Stratum - Cannot connect to eu1.ethermine.org:5555
DevFee: ETH: Stratum - Failed to connect, retry in 20 sec...

my settings are correct and I am mining normally. But your devfee settings are not working and the mining doesn't continue if this is not fixed. Such a great problem. I kept getting this error many times and I lost bunch of times. Tell me what to do if I wasn't controling my screens? I was gonna lose a night maybe?

Check this port it´s a SSL port not a stratum one.

[micalith]

Hey Claymore

Cannot resolve 'eu1.ethermine.org'
ETH: Stratum - Cannot connect to eu1.ethermine.org:5555
DevFee: ETH: Stratum - Failed to connect, retry in 20 sec...

my settings are correct and I am mining normally. But your devfee settings are not working and the mining doesn't continue if this is not fixed. Such a great problem. I kept getting this error many times and I lost bunch of times. Tell me what to do if I wasn't controling my screens? I was gonna lose a night maybe?

Check this port it´s a SSL port not a stratum one.

It is not my mining pool and I don't have a control over it. It is the DevFee pool. My setting for the mining are working fine, but I can't mine for the devfee, it got stuck there and doesn't move, this is annoying a lot.

[adaseb]

I know you can take a log file and if you have a long enough mining duration say 1 month, then you can easily add all the accepted+rejected+stale and get an accurate measurement and being within +- 1% is fairly close.

I think the 1% loss you are talking about is not related to the Claymore software but most likely due to the GPU drivers. I know with my AMD RX series GPUs there is a time when some GPUs hash a little slower for a few seconds and then resume the optimal speed. Been trying to figure out why it happens but couldn't and just left it the way it was because the speed loss was minimal. So find in your logs if your speed was always constant or did it slow down from time to time. You can probably find this easily with MS Excel when you load your log file.

Nobody is talking about speed fluctuations here. The averaged stated speed incorporates them. If miner does not work at some moment it prints 0.000 Mh/s in console (and log) and this zero is heaped when calculating the averaged speed and the number of samples is increased by one for this zero. Come on man use a little the last floor of your body. I talk that this averaged stated speed in console and in the log is 1.5% higher than the real one which can be calculated from the found shares (locally, not at the pools side), difficulty and the time that the miner has worked.

Another way to investigate this further would be for you to switch to a different miner and compare the results after a week or month of mining. I am pretty sure unless you are using the original ethminer included in the ethereum github you should get relatively the same speeds with ETH mining.

So use the other software and take into account the other dev fees and then analyse the results. Use the same rig and same clock settings.

The issue might be that there are lots of new jobs that get sent to the GPUs every few seconds, then when a new job is received the GPUs probably take time to send to the GPU threads and also the current job needs to be dropped and it might result in the 1% loss you are referring too.

How many GPUs do you mine with roughly? Most people with a rig or 2 don't really mind a 1% variance or so.

[RAKOT]

Did anyone succeeded in improving 1060 hashrate with any of v15 tighter straps and what's the rate/GPU?

This how it's most stable on phoenix for me:


Using strap 2 I'm able to see them doing over 26MH, but hashrate jumps around and eventually stabilizes around the same level.

Hello! How much power takes the rig on this speed ?

[Ursul0]

I know you can take a log file and if you have a long enough mining duration say 1 month, then you can easily add all the accepted+rejected+stale and get an accurate measurement and being within +- 1% is fairly close.

I think the 1% loss you are talking about is not related to the Claymore software but most likely due to the GPU drivers. I know with my AMD RX series GPUs there is a time when some GPUs hash a little slower for a few seconds and then resume the optimal speed. Been trying to figure out why it happens but couldn't and just left it the way it was because the speed loss was minimal. So find in your logs if your speed was always constant or did it slow down from time to time. You can probably find this easily with MS Excel when you load your log file.

Nobody is talking about speed fluctuations here. The averaged stated speed incorporates them. If miner does not work at some moment it prints 0.000 Mh/s in console (and log) and this zero is heaped when calculating the averaged speed and the number of samples is increased by one for this zero. Come on man use a little the last floor of your body. I talk that this averaged stated speed in console and in the log is 1.5% higher than the real one which can be calculated from the found shares (locally, not at the pools side), difficulty and the time that the miner has worked.

Another way to investigate this further would be for you to switch to a different miner and compare the results after a week or month of mining. I am pretty sure unless you are using the original ethminer included in the ethereum github you should get relatively the same speeds with ETH mining.

So use the other software and take into account the other dev fees and then analyse the results. Use the same rig and same clock settings.

The issue might be that there are lots of new jobs that get sent to the GPUs every few seconds, then when a new job is received the GPUs probably take time to send to the GPU threads and also the current job needs to be dropped and it might result in the 1% loss you are referring too.

How many GPUs do you mine with roughly? Most people with a rig or 2 don't really mind a 1% variance or so.

Yep. I already suggested bategojko74 will perform comparison analysis with Phoenix miner. that would be interesting.
Also if I understand correctly, he says that the total number of the actual shares produced on the machine according to the logs does not add up to the reported by the miner rate.

[Ursul0]

Did anyone succeeded in improving 1060 hashrate with any of v15 tighter straps and what's the rate/GPU?

This how it's most stable on phoenix for me:


Using strap 2 I'm able to see them doing over 26MH, but hashrate jumps around and eventually stabilizes around the same level.

Hello! How much power takes the rig on this speed ?

 
The miner shows 779W (-mclock +800 -powlim -35 -cclock +100 -tt 67), which should be the combined GPU consumption reported by the driver and it takes actual 975W from the wall - this is with Phoenix miner

With Claymore and strap 1 I've got up to 262MH but the power and hash rate fluctuate widely... hash from 220 to 262 and power goes from 945W to 975W.
It seems that I can make it stable around powlim -32 at 265MH and power around 1010W (still some occasional drops to 970W level)

[RAKOT]

Did anyone succeeded in improving 1060 hashrate with any of v15 tighter straps and what's the rate/GPU?

This how it's most stable on phoenix for me:


Using strap 2 I'm able to see them doing over 26MH, but hashrate jumps around and eventually stabilizes around the same level.

Hello! How much power takes the rig on this speed ?

 
The miner shows 779W (-mclock +800 -powlim -35 -cclock +100 -tt 67), which should be the combined GPU consumption reported by the driver and it takes actual 975W from the wall - this is with Phoenix miner

With Claymore and strap 1 I've got up to 262MH but the power and hash rate fluctuate widely... hash from 220 to 262 and power goes from 945W to 975W.
It seems that I can make it stable around powlim -32 at 265MH and power around 1010W (still some occasional drops to 970W level)

Thank you very much for the detailed answer. Thought to jump from red to green but it seems Ill get not so much power save . My rig of mixed 474-574 runs at the same 240Mhs ( 8 GPUs) - around 1060W from the wall (CM 15).

[Ursul0]

the timing of your question is perfect as I just got installed smart socket with power on/off function and wattmeter there. (my setup is very remote)
also I have on this rig 3*750W PSUs, there were two more vegas in the rig before, so it just stayed connected, wasting wattage and working not efficiently.

So now by lowering -powlim to -37 I run Phoenix at 247.5MH very stable at 945.5-946.4W from the wall

-mclock +800 -powlim -37 -cclock +100 -tt 67

At the same time with the same settings Claymore reports 240-247.2Mh and actual power from the wall fluctuates from 940W to 949W

@Claymore do you have any idea why the fluctuations in power draw?

[lionelnglk]

Hi Everyone,

I can't mine ETC anymore but i still can mine ETH. It keep showing below errors,  

CUDA error - cannot allocate big buffer for DAG. Check readme.txt for possible solutions.

GPU 0 failed

GPU 0, CUDA error 11 - cannot write buffer for DAG

WATCHDOG: GPU error, you need to restart miner

Setting DAG epoch #296(3.31GB)...

i'm using GTX 1050 4gb ram
windows 10
Pagefile intial and max 50gb.
Also tried using these parameters -eres 0, -lidag 0

But error still persist. Anyone knows the solution to this problem? Appreciate all helps. Thks.

[adaseb]

Hi Everyone,

I can't mine ETC anymore but i still can mine ETH. It keep showing below errors,  

CUDA error - cannot allocate big buffer for DAG. Check readme.txt for possible solutions.

GPU 0 failed

GPU 0, CUDA error 11 - cannot write buffer for DAG

WATCHDOG: GPU error, you need to restart miner

Setting DAG epoch #296(3.31GB)...

i'm using GTX 1050 4gb ram
windows 10
Pagefile intial and max 50gb.
Also tried using these parameters -eres 0, -lidag 0

But error still persist. Anyone knows the solution to this problem? Appreciate all helps. Thks.

Windows 10 for some reason uses a lot of GPU memory which results in these errors. The way the operating system works is that it keeps some system data loaded on the GPU and you can't actually use the entire 4GB.

The easiest way to fix this was just to use Linux and you should be good for many many more months.

I had this issue before when my 2GB stopped working and one thing that worked was to put it in a system with a 4GB GPU and make that GPU device 0 and it worked for a while that way. So if you got any other GPUs with 6GB memory of higher try that or just switch to Linux.

[lionelnglk]

Hi Everyone,

I can't mine ETC anymore but i still can mine ETH. It keep showing below errors,  

CUDA error - cannot allocate big buffer for DAG. Check readme.txt for possible solutions.

GPU 0 failed

GPU 0, CUDA error 11 - cannot write buffer for DAG

WATCHDOG: GPU error, you need to restart miner

Setting DAG epoch #296(3.31GB)...

i'm using GTX 1050 4gb ram
windows 10
Pagefile intial and max 50gb.
Also tried using these parameters -eres 0, -lidag 0

But error still persist. Anyone knows the solution to this problem? Appreciate all helps. Thks.

Windows 10 for some reason uses a lot of GPU memory which results in these errors. The way the operating system works is that it keeps some system data loaded on the GPU and you can't actually use the entire 4GB.

The easiest way to fix this was just to use Linux and you should be good for many many more months.

I had this issue before when my 2GB stopped working and one thing that worked was to put it in a system with a 4GB GPU and make that GPU device 0 and it worked for a while that way. So if you got any other GPUs with 6GB memory of higher try that or just switch to Linux.

This GTX 1050 is my spare GPU on my laptop..My main system are using intel GPU. So this GTX GPU should be free from any memory taken up by windows 10.

[bategojko74]

I know you can take a log file and if you have a long enough mining duration say 1 month, then you can easily add all the accepted+rejected+stale and get an accurate measurement and being within +- 1% is fairly close.

I think the 1% loss you are talking about is not related to the Claymore software but most likely due to the GPU drivers. I know with my AMD RX series GPUs there is a time when some GPUs hash a little slower for a few seconds and then resume the optimal speed. Been trying to figure out why it happens but couldn't and just left it the way it was because the speed loss was minimal. So find in your logs if your speed was always constant or did it slow down from time to time. You can probably find this easily with MS Excel when you load your log file.

Nobody is talking about speed fluctuations here. The averaged stated speed incorporates them. If miner does not work at some moment it prints 0.000 Mh/s in console (and log) and this zero is heaped when calculating the averaged speed and the number of samples is increased by one for this zero. Come on man use a little the last floor of your body. I talk that this averaged stated speed in console and in the log is 1.5% higher than the real one which can be calculated from the found shares (locally, not at the pools side), difficulty and the time that the miner has worked.

I'm trying to follow but it's a bit confusing. So now you are claiming that the speed that the miner displays in console and reports to the pool is 1.5% higher than the actual one? and is that somehow related to your previous claim of Claymore taking higher than advertised devfee?

I was wrong that Claymore is taking higher than the advertised devfee. But I am 1000% sure that Claymore shows and reports to pools (if he reports what he shows in console) about 1.5% higher hash rate than the real one.

Ohh I see.
If you are into this kind of action can you maybe do all of us a favor and perform the same analysis on this one https://bitcointalk.org/index.php?topic=2647654.0
And maybe post here with numbers and such?
I know for myself I'd be very much interested to see the actual numbers. Thx.

Partial results for PM 4.6C after two days mining with 10 RX570 + 1 RX580 and 14889 shares found (14799 shares + 90 devfee shares):
https://drive.google.com/open?id=1luXj5zlyeFdXeQ4QL9GcS1t7bSUPzAQd

Compile AverageSpeed.cpp with visual studio

Or if you use GCC compiler:
comment row 4:
//#include "stdafx.h"

and compile it with:
g++ -o AverageSpeed.exe AverageSpeed.cpp

and run it with the following parameters:
AverageSpeed.exe 3 main Eth speed: log20190929_174105.txt

It will produce the averaged stated speed: 316.689 MH/s
The real effective speed is: 14889 (total shares) * 4,000,000,000 (ethermine difficulty) / 188886 (the seconds that the miner has worked) = 315.301 MH/s
So PM shows (316.689 / 315,301 - 1) * 100 = 0.44% higher hashrate than the real effective one. In comparision Claymore shows about 1.5% higher than the real one.
Will update the results when one week ends but 14889 found shares seems to me statistically representative test that will probably produce error under 0.1%. So I expect this 0.44% to finish between 0.34%-0.54% after 5 days.

[adaseb]

Hi Everyone,

I can't mine ETC anymore but i still can mine ETH. It keep showing below errors,  

CUDA error - cannot allocate big buffer for DAG. Check readme.txt for possible solutions.

GPU 0 failed

GPU 0, CUDA error 11 - cannot write buffer for DAG

WATCHDOG: GPU error, you need to restart miner

Setting DAG epoch #296(3.31GB)...

i'm using GTX 1050 4gb ram
windows 10
Pagefile intial and max 50gb.
Also tried using these parameters -eres 0, -lidag 0

But error still persist. Anyone knows the solution to this problem? Appreciate all helps. Thks.

Windows 10 for some reason uses a lot of GPU memory which results in these errors. The way the operating system works is that it keeps some system data loaded on the GPU and you can't actually use the entire 4GB.

The easiest way to fix this was just to use Linux and you should be good for many many more months.

I had this issue before when my 2GB stopped working and one thing that worked was to put it in a system with a 4GB GPU and make that GPU device 0 and it worked for a while that way. So if you got any other GPUs with 6GB memory of higher try that or just switch to Linux.

This GTX 1050 is my spare GPU on my laptop..My main system are using intel GPU. So this GTX GPU should be free from any memory taken up by windows 10.

No I am not talking about your system memory RAM. I am talking about your GDDR which is the memory chips directly on the GPU. When you are using Windows 10 it reserves around 500-700MB of your GDDR for some system data.

For gaming this isn't an issue because the game just stores data on the system RAM and the game still works but with ETH mining the entire DAG needs to fit on the GDDR and if 700MB is taken up by Windows then it will fail.

Try Linux