This now means that the algorithm does not require additional files, which opens the way Asiс .
No asics, I just decided to solve issues with DAG files completely, I planned to do it later but after Wolf0's phrase "goddamned DAGs" I understood that I must do it right now  Now I generate DAGs directly on GPUs so no DAG files are used at all. And no slowdowns on restart? If you have HDD, not SSD, you will see that v4.0 starts much faster. If you have slow CPU you will see the same. |
|
|
|
Great job!
Although speed is slightly lower with 4.0 than 3.3
Speed is the same, but today is new epoch #47, probably you remember speed for epoch #46. |
|
|
|
This now means that the algorithm does not require additional files, which opens the way Asiс .
No asics, I just decided to solve issues with DAG files completely, I planned to do it later but after Wolf0's phrase "goddamned DAGs" I understood that I must do it right now Now I generate DAGs directly on GPUs so no DAG files are used at all. |
|
|
|
|
v4.0:
- no DAG files anymore.
- removed "-dir" option.
- Bug fixes.
|
|
|
|
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.
It takes like 5s to create the goddamned DAG on GPU itself - making epoch switches a breeze, too. The verification on CPU can be done with only the cache... why would you spend so much time implementing something that is more complex and sucks on top of it? Actually I did not spend much time for CRC yet, making DAG on GPU and related changes will require more time. But it seems it can be better to postpone other features and finally solve issues with DAGs completely. |
|
|
|
|
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.
|
|
|
|
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! Perhaps I'm unlucky with PSU. Anyway, 6 390 on 1600W (even downvolted as mentioned) is terrific if it works stable in dual mode. |
|
|
|
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. |
|
|
|
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. |
|
|
|
CLAYMORE i am using your miner to mine another dagger kishimoto based coin and goes fantastic to ver 3.2 but in the new version 3.3 for this feature "CRC check for DAG files" the DAG file rebuld constantly
can you set this feature default but give some command to desactivate it?
It seems disc caching can cause such things, I will improve data flushing to make sure that all data including CRC is written to DAG file immediately after calculation. If it does not help, I will add option to disable CRC check. Also I'm going to add option to disable next DAG creation and option to create several future DAGs (so you can calculate them and copy to all rigs), and set lowest priority for thread that creates next DAG in background, it can help for systems with weak CPUs. |
|
|
|
claymore, i have 15.12 and my 2 x 280x on this new miner are mining aprox 11.6 mhs  what to do? Did they mine faster on v3.2? |
|
|
|
The only one rig has this problem. If I start it without "-allpools 1" option it can't connect to devfee pool and exits. If I start it with this option, then it starts, gets jobs but doesdidn't send the results back. I see in the log file: 12:29:25:775 a88 ETH: put share nonce c8fadd01420866c
12:29:25:775 a88 ETH round found 1 shares
12:29:25:785 10e4 ETH: 04/27/16-12:29:25 - SHARE FOUND - (GPU 2)
12:29:25:785 10e4 send: {"worker":"rig04","id":4,"method":"eth_submitWork","params":["0x0c8fadd01420866c","0x0373b2ccd691ee8dd82b0bf5cf6c6f7fa6b0cad8314253d69f4124659eec3a1e","0xb76e79e4824dca1525ea252fd29fc08a2819959a83331c571a2b16c2c0f6ee59"]}
12:29:25:835 10e4 got 15 bytes
12:29:25:835 10e4 buf: Internal Error
12:29:25:835 10e4 buf: InternalError
DCR is working perfect here. The problem is only with ETH. My start command is EthDcrMiner64.exe -wd 1 -r 0 -epool eth-ru.dwarfpool.com:8008 -ewal 0xXXXXXX -epsw rig04 -dpool stratum+tcp://dcr.suprnova.cc:2252 -dwal gagana.rig04 -eworker rig04 -dpsw x -allpools 1
What could it be? 1. -allpools is ignored for pools that support wallet addresses, like dwarfpool, ethpool, ethermine etc. So you can use -allpools 0 or 1 or remove it at all. 2. Just checked your command line (only set my wallet address) and it works, it finds ETH shares and pool accepts them. |
|
|
|
Sorry, now I remember taht I added allpools 1 to dwarfpool in order to be sure that devfee is mined, can this be a problem?
Setting 1 when its not needed?
-allpools is ignored for pools that support wallet addresses, like dwarfpool, ethpool, ethermine etc. |
|
|
|
Where do you see that -allpools option for every pool defined?
If devfee cannot work on a pool, you won't be able to use this pool, miner will show warning and remove this pool from the list until you add "-allpools 1" option.
Its in the sample epools.txt # POOL: eth-eu.dwarfpool.com:8008, WALLET: 0xD69af2A796A737A103F12d2f0BCC563a13900E6F , PSW: x, WORKER: r270x, ESM: 1, ALLPOOLS: 1
# POOL: us1.ethermine.org:4444, WALLET: 0xD69af2A796A737A103F12d2f0BCC563a13900E6F, PSW: x, WORKER: , ESM: 1, ALLPOOLS: 0
# POOL: coinotron.com:3344, WALLET: YourUserName.YourWorkerName, PSW: YourWorkerPass, WORKER: , ESM: 2, ALLPOOLS: 1 Default epools.txt is a bit different: # POOL: eth-eu.dwarfpool.com:8008, WALLET: 0xD69af2A796A737A103F12d2f0BCC563a13900E6F, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0 # POOL: us1.ethermine.org:4444, WALLET: 0xD69af2A796A737A103F12d2f0BCC563a13900E6F, PSW: x, WORKER: , ESM: 1, ALLPOOLS: 0 # POOL: coinotron.com:3344, WALLET: YourUserName.YourWorkerName, PSW: YourWorkerPass, WORKER: , ESM: 2, ALLPOOLS: 1 So ALLPOOLS is 0 for most pools. It is required only for pools that use USERNAME.WORKER as login or as worker, miner will show warning and removes such pool from the list. PS. I think everyone understands that "#" disables line as explained in readme. I did it because otherwise miner could switch to these pools and if you did not change credentials it will mine but not for you. At startup miner shows how many pools it accepted for ETH and DCR. |
|
|
|
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 ...
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. |
|
|
|
If I use the eth-proxy (stratum proxy) from dwarfpool ( http://dwarfpool.com/static/eth-proxy-win.zip) running on localhost/local network, how do I make this program connect to it ? It already has the wallet address inside the .conf file of stratum. Or is that not supported and I must use the stratum address of dwarfpool directly ? Another question: Are all the "shares" submitted on dwarfpool of equal value ? Or are they weighted according to the difficulty reported by the miner? Also has anyone made some very precise calculations, considering current eth/decred prices and the performance of this merged miner, is it more profitable to mine them both with this program or just one of them? AFAIK Dwarfpool eth-proxy is NOT supported. 2 Claymore, as I see there is -allpools option for every pool defined, what happens when my miner works on pool with allpools 0, if dev fee won't work there? Where do you see that -allpools option for every pool defined? If devfee cannot work on a pool, you won't be able to use this pool, miner will show warning and remove this pool from the list until you add "-allpools 1" option. |
|
|
|
Hi, is there a possibility to build a specific DAG file? ex. #48
No. Why do you need it? Miner creates next DAG in background so there is no pause in mining, and then use it when new epoch is coming and generate next DAG in background, etc. For me when the DAG changes, mining is stopped until next DAG has 40-65% and after that one card (or more) has 0 hashrate, to avoid this I create DAG in advance with ethminer and I use it with your miner. Hmm, what CPU do you have? It takes some time to apply new DAG, may be it's a good idea to start creation next DAG in a few minutes. |
|
|
|
Hi, is there a possibility to build a specific DAG file? ex. #48
No. Why do you need it? Miner creates next DAG in background so there is no pause in mining, and then use it when new epoch is coming and generate next DAG in background, etc. |
|
|
|
|
v3.3:
- failover for both Ethereum and Decred.
- added CRC check for DAG files. Now if DAG file is corrupted, miner will detect it and re-create DAG.
Don't remove DAG files manually if you think that they can be corrupted - miner will do it automatically if necessary.
- default value for "-ethi" option is "8" now (instead of "16"), it slightly reduces delays when miner accepts new job.
- Bug fixes, a few minor improvements.
Note that this version will recreate DAG files because old DAGs don't have built-in CRC. If you also want to use old versions of miner, use "-dir" option to set different folders for DAG files because CRC makes DAG files incompatible between v3.3 and earlier versions.
|
|
|
|
Another feature that i'd like to suggest is a way to for us to identify which card on a rig relates to the GPU number. The only way I can think of doing this would be, for example, if you hit CTRL+0, then it will adjust GPU#0's FAN to 100% while adjusting all other GPU fans on that rig to 5% for 15 seconds, that way we can know that GPU0 will be the card on the rig thats running the fans at full speed. This would be a huge help with troubleshooting hardware.
Can second this - GPU ordering is totally wack in this miner. GPU-Z, Afterburner, etc seem to show the GPUs in a totally different order. True, one can always see temps in the miner and try to match them in gpu-z to see "what's what". I can add to this that claymore miner isn't internally consistent. Order of GPUs shown in mining stats messages doesn't match order of GPUs shown in temperature stats messages. Not the end of the world, but it can be confusing. Yes I got some feedbacks about it though I cannot reproduce it on my test rigs for now. The reason is simple: in miner I have to enumerate GPUs via OpenCL API to execute OpenCL code, and I have to enumerate them via ADL API to manage temperature/clock. And order of GPUs in these lists can be different. Such behaiour is senseless for me, but AMD developers always think in a different way. Right now I have no idea how to find same cards in both lists to syncrhonize them. |
|
|
|
|
Show Posts
