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

kirilvvbg

full member

Activity: 213

Merit: 100

Quote from: Claymore on April 28, 2016, 07:51:45 PM

Quote from: o00o on April 28, 2016, 07:19:32 PM

Quote from: Claymore on April 28, 2016, 06:39:45 PM

Quote from: o00o on April 28, 2016, 06:07:43 PM

@ 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?

3.25 only because of WIN 7

restless

legendary

Activity: 1151

Merit: 1001

Quote from: o00o on April 28, 2016, 08:18:36 PM

I'm guessing my memory controller hub can only allocate up to 3.25GB of memory. I inspected the motherboard's bios in hopes of finding an option which would allow me to remove RAM reserved for GPU but none was available.

I exhausted every possible solution which crossed my mind.

Why not using v4.0 ?

Hoang152

newbie

Activity: 33

Merit: 0

My command, Working good!
EthDcrMiner64.exe -epool eth-eu.dwarfpool.com:8008 -ewal 0xc81464ffc7fe69ddb574d69fc6b0bab6cf993325 -epsw x -dpool stratum+tcp://dcr.suprnova.cc:2252 -dwal Hoang152.1 -dpsw batiu152 -tt 75 -dcri 20 -r 0

kanoptx

sr. member

Activity: 406

Merit: 250

www.cryptocompare.com

I've been getting around 2000mh. which according to this calculator: http://decred-calc.cryptohub.info/ should give me about 1.40 dcr. i'm getting around 1.10. is this normal? is it something to do with dual mining? i've changed to supernova, and same thing... is it the calculator? thx

o00o

member

Activity: 93

Merit: 11

Quote from: Eyedol-X on April 28, 2016, 07:47:18 PM

Quote from: o00o on April 28, 2016, 07:19:32 PM

Quote from: Claymore on April 28, 2016, 06:39:45 PM

Quote from: o00o on April 28, 2016, 06:07:43 PM

@ 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.

I've already done so but thanks for your advice nonetheless!

Quote from: Claymore on April 28, 2016, 07:51:45 PM

Quote from: o00o on April 28, 2016, 07:19:32 PM

Quote from: Claymore on April 28, 2016, 06:39:45 PM

Quote from: o00o on April 28, 2016, 06:07:43 PM

@ 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?

I'm guessing my memory controller hub can only allocate up to 3.25GB of memory. I inspected the motherboard's bios in hopes of finding an option which would allow me to remove RAM reserved for GPU but none was available.

I exhausted every possible solution which crossed my mind.

davembg

sr. member

Activity: 340

Merit: 251

Smell the glove.

Quote from: Claymore on April 28, 2016, 07:53:14 PM

Quote from: kirilvvbg on April 28, 2016, 07:05:47 PM

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.

Is there source for Linux users?

Claymore

donator

Activity: 1610

Merit: 1325

Miners developer

Quote from: kirilvvbg on April 28, 2016, 07:05:47 PM

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.

Claymore

donator

Activity: 1610

Merit: 1325

Miners developer

Quote from: o00o on April 28, 2016, 07:19:32 PM

Quote from: Claymore on April 28, 2016, 06:39:45 PM

Quote from: o00o on April 28, 2016, 06:07:43 PM

@ 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?

Eyedol-X

hero member

Activity: 952

Merit: 508

Quote from: o00o on April 28, 2016, 07:19:32 PM

Quote from: Claymore on April 28, 2016, 06:39:45 PM

Quote from: o00o on April 28, 2016, 06:07:43 PM

@ 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.

o00o

member

Activity: 93

Merit: 11

Quote from: Claymore on April 28, 2016, 06:39:45 PM

Quote from: o00o on April 28, 2016, 06:07:43 PM

@ 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!

kirilvvbg

full member

Activity: 213

Merit: 100

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.

Claymore

donator

Activity: 1610

Merit: 1325

Miners developer

Quote from: Eyedol-X on April 28, 2016, 06:37:45 PM

Quote from: Claymore on April 28, 2016, 10:46:29 AM

Quote from: Eyedol-X on April 28, 2016, 10:26:50 AM

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.

Claymore

donator

Activity: 1610

Merit: 1325

Miners developer

Quote from: o00o on April 28, 2016, 06:07:43 PM

@ 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.

Eyedol-X

hero member

Activity: 952

Merit: 508

Quote from: Claymore on April 28, 2016, 10:46:29 AM

Quote from: Eyedol-X on April 28, 2016, 10:26:50 AM

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.

o00o

member

Activity: 93

Merit: 11

@ 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!

revelacaogr

legendary

Activity: 1316

Merit: 1021

2009 Alea iacta est

Quote from: Claymore on April 28, 2016, 04:31:15 PM

Quote from: revelacaogr on April 28, 2016, 03:31:20 PM

@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

freeapp

member

Activity: 137

Merit: 10

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

phzi

hero member

Activity: 700

Merit: 500

Quote from: crazyearner on April 28, 2016, 04:46:26 PM

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

member

Activity: 137

Merit: 10

Quote from: Claymore on April 28, 2016, 04:31:15 PM

Quote from: revelacaogr on April 28, 2016, 03:31:20 PM

@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

crazyearner

legendary

Activity: 1820

Merit: 1001

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 ?

Topic: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v15.0 (Windows/Linux) - page 1348. (Read 6590565 times)