Topic: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v15.0 (Windows/Linux) - page 1354. (Read 6590757 times)
April 27, 2016, 02:31:21 AM
Wolf0, could you check this thread pls. https://bitcointalk.org/index.php?topic=1366011.80
April 27, 2016, 12:28:41 AM
What about 2GB GPUs - will they be able to create new DAG in video memory too? (I guess so, but...)
April 26, 2016, 10:42:05 PM
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 to the most recent build. 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 Claymore's but that also didn't work. My other rig surprisingly doesn't suffer from this symptom.
April 26, 2016, 07:59:17 PM
stratum socket send failure 10053 i've been getting this alot lately from supernove. why? :\ it connects again rly fast though :\
I'm getting the same on dwarfpool. It happens just after finding a share and rejecting it.
April 26, 2016, 07:37:04 PM
Since using your client, i've only been running in pure ETH mode (no DCR mining)
Since my rigs have been running super stable, I thought i'd try dual mining mode.
I reconfigured my command line according to your example for dcr.suprnova.cc and started it up.
Everything connected and then started hashing away. Shares were being submitted for both, but after 1-2 minutes of mining, the whole rig freezes up.
At first I thought it was because I didn't set the virtual memory to 16384 (I have 8GB in each rig - never set the virtual mem settings as everything ran fine while mining ETH) so I made the setting and restarted.
Still crashing after 1-2 minutes. So I reduced the OC on my cards to stock levels.
Still crashing after 1-2 minutes.
Thought this was a rig issue, so I tried dual mining on another newer rig with different cards and hardware (both running Windows 8 x64 with 8GB RAM). Still the same problem is happening.
Log files show that it always crashes after a few DCR shares have been found.
I'm not sure why this is happening. I've since gone back to ETH only mining mode, and things are stable as usual. Is this a bug with v3.3?
Since my rigs have been running super stable, I thought i'd try dual mining mode.
I reconfigured my command line according to your example for dcr.suprnova.cc and started it up.
Everything connected and then started hashing away. Shares were being submitted for both, but after 1-2 minutes of mining, the whole rig freezes up.
At first I thought it was because I didn't set the virtual memory to 16384 (I have 8GB in each rig - never set the virtual mem settings as everything ran fine while mining ETH) so I made the setting and restarted.
Still crashing after 1-2 minutes. So I reduced the OC on my cards to stock levels.
Still crashing after 1-2 minutes.
Thought this was a rig issue, so I tried dual mining on another newer rig with different cards and hardware (both running Windows 8 x64 with 8GB RAM). Still the same problem is happening.
Log files show that it always crashes after a few DCR shares have been found.
I'm not sure why this is happening. I've since gone back to ETH only mining mode, and things are stable as usual. Is this a bug with v3.3?
think i may try this for my r9 290... setting it to eth only. i tried setting ethi to 0. it's been doing like 20,21. not sure if it will freeze or not.. it's a shame, this works so good on my r9 280x
April 26, 2016, 07:20:45 PM
to me - it doesn't seem worth it to duel mine . BTC per day is less than mining either of them directly
Ether 20M h/s normally get 22-24
DRC - 300 Mh/s normally get 1.3 Gh/s
Ether 20M h/s normally get 22-24
DRC - 300 Mh/s normally get 1.3 Gh/s
yeah but here you're getting both..
April 26, 2016, 07:16:49 PM
stratum socket send failure 10053 i've been getting this alot lately from supernove. why? :\ it connects again rly fast though :\
April 26, 2016, 07:01:10 PM
to me - it doesn't seem worth it to duel mine . BTC per day is less than mining either of them directly
Ether 20M h/s normally get 22-24
DRC - 300 Mh/s normally get 1.3 Gh/s
Ether 20M h/s normally get 22-24
DRC - 300 Mh/s normally get 1.3 Gh/s
April 26, 2016, 06:52:40 PM
Since using your client, i've only been running in pure ETH mode (no DCR mining)
Since my rigs have been running super stable, I thought i'd try dual mining mode.
I reconfigured my command line according to your example for dcr.suprnova.cc and started it up.
Everything connected and then started hashing away. Shares were being submitted for both, but after 1-2 minutes of mining, the whole rig freezes up.
At first I thought it was because I didn't set the virtual memory to 16384 (I have 8GB in each rig - never set the virtual mem settings as everything ran fine while mining ETH) so I made the setting and restarted.
Still crashing after 1-2 minutes. So I reduced the OC on my cards to stock levels.
Still crashing after 1-2 minutes.
Thought this was a rig issue, so I tried dual mining on another newer rig with different cards and hardware (both running Windows 8 x64 with 8GB RAM). Still the same problem is happening.
Log files show that it always crashes after a few DCR shares have been found.
I'm not sure why this is happening. I've since gone back to ETH only mining mode, and things are stable as usual. Is this a bug with v3.3?
Since my rigs have been running super stable, I thought i'd try dual mining mode.
I reconfigured my command line according to your example for dcr.suprnova.cc and started it up.
Everything connected and then started hashing away. Shares were being submitted for both, but after 1-2 minutes of mining, the whole rig freezes up.
At first I thought it was because I didn't set the virtual memory to 16384 (I have 8GB in each rig - never set the virtual mem settings as everything ran fine while mining ETH) so I made the setting and restarted.
Still crashing after 1-2 minutes. So I reduced the OC on my cards to stock levels.
Still crashing after 1-2 minutes.
Thought this was a rig issue, so I tried dual mining on another newer rig with different cards and hardware (both running Windows 8 x64 with 8GB RAM). Still the same problem is happening.
Log files show that it always crashes after a few DCR shares have been found.
I'm not sure why this is happening. I've since gone back to ETH only mining mode, and things are stable as usual. Is this a bug with v3.3?
April 26, 2016, 06:27:28 PM
BTW this CRC check is way harder for low-end CPUs, while creating DAG mining is almost at zero hashrate(95-99% less than full speed), with previous versions it was mining with 30% less hashrate.
Yep, this is my only complain about this new version. My rigs use Celerons G1840 and they have a hard time computing the new DAG, reducing the hashrate almost to zero
But once the DAG is complete... my rigs don't freeze, don't complain, don't moan...they just mine!
April 26, 2016, 06:23:28 PM
2. Just checked your command line (only set my wallet address) and it works, it finds ETH shares and pool accepts them.
I deleted a symbol from the middle of the wallet address in the command line somehow.
So, it was 19 digits only. This was the problem. April 26, 2016, 06:19:11 PM
I already got some feedback and logs, soon I will release an update with improvements related to CRC. Since I found that some people use DAGs from ethminer I will return compatibilty with it, but still will check CRC. To avoid freezes I will start next DAG calculation not immediately but a bit later and will do it with idle priority. Also there will be options to create several future DAGs or disable next DAG creation.
Fantastic!BTW this CRC check is way harder for low-end CPUs, while creating DAG mining is almost at zero hashrate(95-99% less than full speed), with previous versions it was mining with 30% less hashrate.
April 26, 2016, 04:33:14 PM
v3.3 has just made my life a lot easier. The reboot feature on GPU failure works flawlessly, and the logging has made it super easy to identify issues. Big thanks to you again Claymore for this awesome miner. The only thing left to do now is find a way to help us miners find out which card is "GPU1" (or GPUx). Is the idea I suggested earlier about temporarily adjusting FAN speed on a single card to 100% and dropping the remaining cards to 5-15% in order to help us identify a particular card still possible?
April 26, 2016, 02:29:53 PM
I already got some feedback and logs, soon I will release an update with improvements related to CRC. Since I found that some people use DAGs from ethminer I will return compatibilty with it, but still will check CRC. To avoid freezes I will start next DAG calculation not immediately but a bit later and will do it with idle priority. Also there will be options to create several future DAGs or disable next DAG creation.
DAG file compatibility with ethminer is awesome! Thanks! 
April 26, 2016, 02:00:53 PM
I already got some feedback and logs, soon I will release an update with improvements related to CRC. Since I found that some people use DAGs from ethminer I will return compatibilty with it, but still will check CRC. To avoid freezes I will start next DAG calculation not immediately but a bit later and will do it with idle priority. Also there will be options to create several future DAGs or disable next DAG creation.
April 26, 2016, 01:35:00 PM
ver 3.3 is bad for machines with weak cpu/hdd
Many freezes when finished generating first dag, then starting next one and attempt to start mining.
Also I had several "crc dag fail" after normal miner restart.
I'm back to 3.2 - it is cool! But I miss failover option.
Can we disable crc check somehow? I had no problem with corrupted DAG's before with Claymore miner ...
Many freezes when finished generating first dag, then starting next one and attempt to start mining.
Also I had several "crc dag fail" after normal miner restart.
I'm back to 3.2 - it is cool! But I miss failover option.
Can we disable crc check somehow? I had no problem with corrupted DAG's before with Claymore miner ...
I had problems with DAG on one of my test rigs after hard reboot. It sent wrong shares for a few hours before I noticed that something is wrong.
DAG file size was ok and it had correct signature at beginning, but it was corrupted. So I think checking CRC is necessary.
PM me some logs so I can check the details. I can postpone next DAG generation for a few minutes and/or reduce CPU load for it.
Anyway, v3.2 creates next DAG too, so you must see same freezes. The only difference is CRC check when DAG is loaded, but it must not take more than 2-4 seconds even on slow CPU.
I checked my log files and i'm afraid you won't find any usefull info in it. Only bad crc after each start and sudden end of log file after 1 dag generation (the system hangs). And then after restart all over again.
Code:
10:29:22:637 524 DAG creation: 100%% done...
10:29:24:165 524 DAG file (epoch #46) is ok.
10:29:24:181 524 Need to check next DAG file (epoch #47) in background, starting...
10:29:24:197 524 Applying DAG epoch #46 for GPU #0
10:29:24:197 524 Create GPU buffer for GPU #0
10:29:26:911 8ec ETH: checking pool connection...
10:29:26:927 8ec send: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
10:29:27:005 8ec got 244 bytes
10:29:27:192 8ec buf: {"result":["0x8bb8683bdc4ed703beafe7e72f12b38b6d37d6b4bb91e14f4e87e16cf704dea3","0xd6a8400b7f4cc5e082e8239662ed0ee7162892f74016107a7586195f4d591efb","0x0000000225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"],"jsonrpc":"2.0","id":3}
10:29:27:192 8ec parse packet: 243
10:29:27:207 8ec eth: job is the same
10:29:27:207 8ec remove first packet 1
10:29:27:207 8ec new buf size: 1
10:29:27:223 8ec buf:
You previous DAG managment implementation was brilliant and failsafe. Now it cannot deal with possible hardware or software errors.
I returned to 3.2 and it works like a charm.
I cannot test 3.3 again as it is on remote machine now and I have no possibility to restart it if it will hang again.
April 26, 2016, 12:07:43 PM
2X1000W, Corsair RM1000X (already ordered add2PSU but it has not arrived yet, so thus manual start)
I was unable to make work 3 390 (stock) on 1000W PSU, it failed in a few minutes of work, have to use 3 1000W PSU for 6 390. But 2 1200W can handle 6 390 in all my tests.
I understand but "citronick" previous post use EVGA 1600W 6X390 GPU. So not understand why is not enough 2X1000W PSU in this case?! Thank you Claymore!
I use -100mV/1015mhz/1500mhz setting using MSI Afterburner utility -- this setting under-clocks the 390s to be just under 1600 (sometimes it goes above 1600w).
But fellow riggers have advised me not to do this because it will surely kill the PSU...
If you want to keep the 6 card setup at stock clock speeds, confirm you need 2 PSUs or even 3 PSUs like Claymore mentioned.
Each 390 at stock is I think 270w each. So 270 x 6 is already 1620w excluding mobo etc.
Thank you Citronick and Claymore i used all settings and connected MOLEX so i now test
April 26, 2016, 11:52:52 AM
what if we dont want to mine ethereum, can we mine other dagger-hashimoto coins (with decred dual mining combo)
you can mine expanse
April 26, 2016, 11:44:23 AM
what if we dont want to mine ethereum, can we mine other dagger-hashimoto coins (with decred dual mining combo)
April 26, 2016, 11:17:21 AM
Any news about stratum implementation for solo ETH ?
Bumped up for you qqqq.
Claymore, can you confirm if solo ETH version, will have the dual mining feature enabled (ie. ETH solo and DCR mining), or can we select solo ETH only? Thanks
Solo version will have both eth and eth+dcr modes. I will release it in a few days.
Thanks a lot!
Thanks Claymore for the dates on solo ETH -- it will be a good solution for big miners.
Jump to: