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

[Bazelak]

The DAG is generated in the GPU directly now. Do we still need to set more than 16 GB virtual memory?

[1714078602]

1714078602

[1714078602]

1714078602

[1714078602]

1714078602

[revelacaogr]

no....DAG creation IN gpu

[revelacaogr]

@Claymore

can this help u eccelerate the speed of yr miner?

New miner binaries now available! Updated the OP text to reflect the release. Big thanks to Epsylon3 and Wolf0 who completed RFP-5 milestones that made this release possible! More information in the announcement.

https://forum.decred.org/threads/new-miner-binaries-now-available.3409/

i just ask....
tks

[reflexmk]

First I want to say, great miner -- Nicely done Claymore.

Been reading about this for a few weeks and just fired it off on my rig last night so version 4.0 is the first version I have used.

4.0 mined all night then for whatever reason this morning, just stopped mining but GPU loads and Miner reported hash rate remained unchanged.

I noticed after 2 hours the pool indicated the effective hash rate was 0 but the miner was still reporting an unchanged hash rate to the pool.

I quit/relaunched the miner and didn't see a change within a few minutes, so I switched to a different miner (without rebooting) and it started up just fine.
----Note: I may not have waited long enough for the pool to update its reporting before I switched miners.

Don't know if this information helps you or the community but I figured I would share it.

System specs as of right now
Windows 10 X64
2x R9 380X
Crimson 15.12 Drivers

happened to me also, 2 times for more than 3 hours at a time

win7 64bit
15.12 crimson
8gb ram
24gb virtual memory
2x r7 370 (4gb)

[Claymore]

First I want to say, great miner -- Nicely done Claymore.

Been reading about this for a few weeks and just fired it off on my rig last night so version 4.0 is the first version I have used.

4.0 mined all night then for whatever reason this morning, just stopped mining but GPU loads and Miner reported hash rate remained unchanged.

I noticed after 2 hours the pool indicated the effective hash rate was 0 but the miner was still reporting an unchanged hash rate to the pool.

I quit/relaunched the miner and didn't see a change within a few minutes, so I switched to a different miner (without rebooting) and it started up just fine.
----Note: I may not have waited long enough for the pool to update its reporting before I switched miners.

Don't know if this information helps you or the community but I figured I would share it.

System specs as of right now
Windows 10 X64
2x R9 380X
Crimson 15.12 Drivers

happened to me also, 2 times for more than 3 hours at a time

win7 64bit
15.12 crimson
8gb ram
24gb virtual memory
2x r7 370 (4gb)

Send me the log file as soon as you see such behaviour. I set "-dbg 0" by default exactly for such cases. Right now I don't have even single log related to this issue.

[Claymore]

@Claymore

can this help u eccelerate the speed of yr miner?

New miner binaries now available! Updated the OP text to reflect the release. Big thanks to Epsylon3 and Wolf0 who completed RFP-5 milestones that made this release possible! More information in the announcement.

https://forum.decred.org/threads/new-miner-binaries-now-available.3409/

i just ask....
tks

In that thread I don't see any comments that confirm that new release is faster for AMD. Though I know how to speedup DCR mining by 5-10% and will do it in future.

[crazyearner]

SO with no more DAG files needed then how does this effect the hash speed as thing move on as bigger DAG files use to get less speeds use to get. So does this mean should see a improvement in speeds from cards when DAG use be smaller on size n bigger on hashes ?

[freeapp]

@Claymore

can this help u eccelerate the speed of yr miner?

New miner binaries now available! Updated the OP text to reflect the release. Big thanks to Epsylon3 and Wolf0 who completed RFP-5 milestones that made this release possible! More information in the announcement.

https://forum.decred.org/threads/new-miner-binaries-now-available.3409/

i just ask....
tks

In that thread I don't see any comments that confirm that new release is faster for AMD. Though I know how to speedup DCR mining by 5-10% and will do it in future.

Hi,
i get on my 7970 the following:
ETH: 14,5 MH/s
DCR: 720 MH/s

with native ethminer i get about 17 MH/s
and with sgminer for decred i get about 1.1 GH/s

i use the following settings:
EthDcrMiner64.exe -etha 1 -esm 2 -dbg -1 -allpools 1 -di 2 -epool stratum+tcp://eth.coinmine.pl:4000 -ewal user.eth -epsw x -dpool stratum+tcp://dcr.suprnova.cc:2252 -dwal user.dcr -dpsw x -dcri 100

[phzi]

SO with no more DAG files needed then how does this effect the hash speed as thing move on as bigger DAG files use to get less speeds use to get. So does this mean should see a improvement in speeds from cards when DAG use be smaller on size n bigger on hashes ?

v4 doesn't change anything about how the DAG is used, just how it is generated and stored.  The dagger working set will continue to grow each epoch, and if your GPU slows down more because of tlb issues as the dag grows, it will still do that.

Before, the CPU would calculate the DAG, it was stored on the hard drive, and transferred to the GPU memory over the pci-e bus.  Now, only the dag cache is pushed to the GPU, and the DAG is generated on the GPU (and never stored on HDD or in CPU accessed RAM) and only stored in VRAM.

In short, it's a bloody awesome improvement!

--

@freeapp that sounds right if you're using dcri 100.  Dcr mining is a "bonus" in between ethash gpu usage when it's busy with vram accesses.  Values between 20 and 40 seem optimal for different GPUs and result in the same or increased ethash performance with moderate decred performance.

[freeapp]

maybe another stupid question, but is this miner MiningRigRentals compatible?

[revelacaogr]

@Claymore

can this help u eccelerate the speed of yr miner?

New miner binaries now available! Updated the OP text to reflect the release. Big thanks to Epsylon3 and Wolf0 who completed RFP-5 milestones that made this release possible! More information in the announcement.

https://forum.decred.org/threads/new-miner-binaries-now-available.3409/

i just ask....
tks

In that thread I don't see any comments that confirm that new release is faster for AMD. Though I know how to speedup DCR mining by 5-10% and will do it in future.

ok tks

[o00o]

@ Claymore

I updated to v3.3 from a previous 3.x version and was no longer able to mine due to failing to create a big buffer.  I was forced to revert to v 1.2 to resolve the issue as any other builds replicate the problem.  Absolutely no changes were made to the system in question; all I did was close the previously working miner and updated the directory's contents. All environment variables have been set as well as 2 x 8 GB pagefiles and I've also removed temp files as well as the dag directory which I additionally decided to provide an alternate one on a seperate hard drive to hopefully eliminate the problem.  I also tried renaming the dag files successfully created by QTminer in hopes of using them with yours but that also didn't work. My other rig is also Hawaii-based and surprisingly doesn't suffer from this symptom.  I just gave v4.0 a try but it still introduces the same error.

Any feedback would be much appreciated!

[Eyedol-X]

First I want to say, great miner -- Nicely done Claymore.

Been reading about this for a few weeks and just fired it off on my rig last night so version 4.0 is the first version I have used.

4.0 mined all night then for whatever reason this morning, just stopped mining but GPU loads and Miner reported hash rate remained unchanged.

I noticed after 2 hours the pool indicated the effective hash rate was 0 but the miner was still reporting an unchanged hash rate to the pool.

I quit/relaunched the miner and didn't see a change within a few minutes, so I switched to a different miner (without rebooting) and it started up just fine.
----Note: I may not have waited long enough for the pool to update its reporting before I switched miners.

Don't know if this information helps you or the community but I figured I would share it.

System specs as of right now
Windows 10 X64
2x R9 380X
Crimson 15.12 Drivers

Miner shows goot hashrate, so it must send shares, but pool shows zero rate? PM me log file and command line that you use.

PM Sent with Link to log file.

forgot to mention the system that this occurred on has a SSD and 16GB of Ram, do not know if that is relevant to this problem or not.

[Claymore]

@ Claymore

I updated to v3.3 from a previous 3.x version and was no longer able to mine due to failing to create a big buffer.  I was forced to revert to v 1.2 to resolve the issue as any other builds replicate the problem.  Absolutely no changes were made to the system in question; all I did was close the previously working miner and updated the directory's contents. All environment variables have been set as well as 2 x 8 GB pagefiles and I've also removed temp files as well as the dag directory which I additionally decided to provide an alternate one on a seperate hard drive to hopefully eliminate the problem.  I also tried renaming the dag files successfully created by QTminer in hopes of using them with yours but that also didn't work. My other rig is also Hawaii-based and surprisingly doesn't suffer from this symptom.  I just gave v4.0 a try but it still introduces the same error.

Any feedback would be much appreciated!

v3.3 takes may be 10-20 more GPU memory, that's the only difference between previous versions. You even did not mention what cards are used, how much RAM etc.

[Claymore]

First I want to say, great miner -- Nicely done Claymore.

Been reading about this for a few weeks and just fired it off on my rig last night so version 4.0 is the first version I have used.

4.0 mined all night then for whatever reason this morning, just stopped mining but GPU loads and Miner reported hash rate remained unchanged.

I noticed after 2 hours the pool indicated the effective hash rate was 0 but the miner was still reporting an unchanged hash rate to the pool.

I quit/relaunched the miner and didn't see a change within a few minutes, so I switched to a different miner (without rebooting) and it started up just fine.
----Note: I may not have waited long enough for the pool to update its reporting before I switched miners.

Don't know if this information helps you or the community but I figured I would share it.

System specs as of right now
Windows 10 X64
2x R9 380X
Crimson 15.12 Drivers

Miner shows goot hashrate, so it must send shares, but pool shows zero rate? PM me log file and command line that you use.

PM Sent with Link to log file.

forgot to mention the system that this occurred on has a SSD and 16GB of Ram, do not know if that is relevant to this problem or not.

Issue confirmed and will be fixed in next update by adding watchdog for all miner threads, not only GPU-related threads.

[kirilvvbg]

Well done, Claymore. The only thing missing so far is e-mail notification.
Or may be, I am wrong, and you have this option too? Couldn't find it anyway.

[o00o]

@ Claymore

I updated to v3.3 from a previous 3.x version and was no longer able to mine due to failing to create a big buffer.  I was forced to revert to v 1.2 to resolve the issue as any other builds replicate the problem.  Absolutely no changes were made to the system in question; all I did was close the previously working miner and updated the directory's contents. All environment variables have been set as well as 2 x 8 GB pagefiles and I've also removed temp files as well as the dag directory which I additionally decided to provide an alternate one on a seperate hard drive to hopefully eliminate the problem.  I also tried renaming the dag files successfully created by QTminer in hopes of using them with yours but that also didn't work. My other rig is also Hawaii-based and surprisingly doesn't suffer from this symptom.  I just gave v4.0 a try but it still introduces the same error.

Any feedback would be much appreciated!

v3.3 takes may be 10-20 more GPU memory, that's the only difference between previous versions. You even did not mention what cards are used, how much RAM etc.

I'm clueless as to why all versions excluding v1.2 fail to create a big buffer despite the fact that they were previously working prior to updating to v3.3. I did mention that the rig in question is seated with a Hawaii-based GPU, more precisely a reference Sapphire 290x operating on Windows 7 x64, Intel Pentium D w/ 2 x 2GB RAM although only 3.25 GB are usable.  I can send you my log along with any other information deem it necessary.

Thanks for the quick reply!

[Eyedol-X]

@ Claymore

I updated to v3.3 from a previous 3.x version and was no longer able to mine due to failing to create a big buffer.  I was forced to revert to v 1.2 to resolve the issue as any other builds replicate the problem.  Absolutely no changes were made to the system in question; all I did was close the previously working miner and updated the directory's contents. All environment variables have been set as well as 2 x 8 GB pagefiles and I've also removed temp files as well as the dag directory which I additionally decided to provide an alternate one on a seperate hard drive to hopefully eliminate the problem.  I also tried renaming the dag files successfully created by QTminer in hopes of using them with yours but that also didn't work. My other rig is also Hawaii-based and surprisingly doesn't suffer from this symptom.  I just gave v4.0 a try but it still introduces the same error.

Any feedback would be much appreciated!

v3.3 takes may be 10-20 more GPU memory, that's the only difference between previous versions. You even did not mention what cards are used, how much RAM etc.

I'm clueless as to why all versions excluding v1.2 fail to create a big buffer despite the fact that they were previously working prior to updating to v3.3. I did mention that the rig in question is seated with a Hawaii-based GPU, more precisely a reference Sapphire 290x operating on Windows 7 x64, Intel Pentium D w/ 2 x 2GB RAM although only 3.25 GB are usable.  I can send you my log along with any other information deem it necessary.

Thanks for the quick reply!

Hope my .02 can help with your issue,

Just my gut here but I'm betting you're running out of system memory(ram) when attempting to mine. I just checked one of my single card rigs and it's using 3GB of Ram while running a ETH miner.

...could try setting a huge pagefiles but this doesn't completely substitute ram in Windows.

[Claymore]

@ Claymore

I updated to v3.3 from a previous 3.x version and was no longer able to mine due to failing to create a big buffer.  I was forced to revert to v 1.2 to resolve the issue as any other builds replicate the problem.  Absolutely no changes were made to the system in question; all I did was close the previously working miner and updated the directory's contents. All environment variables have been set as well as 2 x 8 GB pagefiles and I've also removed temp files as well as the dag directory which I additionally decided to provide an alternate one on a seperate hard drive to hopefully eliminate the problem.  I also tried renaming the dag files successfully created by QTminer in hopes of using them with yours but that also didn't work. My other rig is also Hawaii-based and surprisingly doesn't suffer from this symptom.  I just gave v4.0 a try but it still introduces the same error.

Any feedback would be much appreciated!

v3.3 takes may be 10-20 more GPU memory, that's the only difference between previous versions. You even did not mention what cards are used, how much RAM etc.

I'm clueless as to why all versions excluding v1.2 fail to create a big buffer despite the fact that they were previously working prior to updating to v3.3. I did mention that the rig in question is seated with a Hawaii-based GPU, more precisely a reference Sapphire 290x operating on Windows 7 x64, Intel Pentium D w/ 2 x 2GB RAM although only 3.25 GB are usable.  I can send you my log along with any other information deem it necessary.

Thanks for the quick reply!

Why only 3.25GB are usable?

[Claymore]

Well done, Claymore. The only thing missing so far is e-mail notification.
Or may be, I am wrong, and you have this option too? Couldn't find it anyway.

I'll try to add it in next update.