There is a problem with Zclassic mining. With allpools 1 option at zcl.coinmine.pl when miner tries to mine devfee it tries to coonect with ssl, but there is no ssl support at zcl.coinmine. How i can avoid this?
v9.3 and "-allpools 1" will work. |
|
|
|
@Claymore
I am getting constant devfee DAG creation errors and constant crashes of the miner. ! The moement devfee DAG creation starts from dwarfpool; it crashes immediately with this error 18:09:21:751 87c DevFee: ETH: Stratum - connecting to 'eth-eu.dwarfpool.com' <87.98.182.61> port 8008
18:09:21:888 87c send: {"worker": "eth1.0", "jsonrpc": "2.0", "params": ["0xe19fFB70E148A76d26698036A9fFD22057967D1b", "x"], "id": 2, "method": "eth_submitLogin"}
18:09:21:889 87c DevFee: ETH: Stratum - Connected (eth-eu.dwarfpool.com:8008)
18:09:22:024 87c got 39 bytes
18:09:22:024 87c buf: {"id":2,"jsonrpc":"2.0","result":true}
18:09:22:024 87c parse packet: 38
18:09:22:024 87c ETH: Authorized
18:09:22:024 87c send: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
18:09:22:024 87c new buf size: 0
18:09:22:163 87c got 244 bytes
18:09:22:163 87c buf: {"result":["0xd91c11bf6e42ba9dda8d6c80488bd3ce943989494b3ffbc59c634ee7645ba0d8","0xb0a52850ea22f7b03f44593e27552c6d850e40a9f6b92fbf1d15586b6affbccb","0x0000000225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"],"jsonrpc":"2.0","id":3}
18:09:22:163 87c parse packet: 242
18:09:22:163 87c ETH: job changed
18:09:22:163 87c new buf size: 0
18:09:22:164 87c DevFee: start mining
18:09:22:346 344 Setting DAG epoch #96...
18:09:23:987 344 Setting DAG epoch #96 for GPU #0
18:09:23:987 924 Setting DAG epoch #96 for GPU #3
18:09:23:987 8e0 Setting DAG epoch #96 for GPU #2
18:09:23:993 a78 Setting DAG epoch #96 for GPU #1
18:09:24:256 d7c recv: 51
18:09:24:256 d7c srv pck: 50
18:09:24:281 d7c srv bs: 0
18:09:24:281 d7c sent: 203
18:09:29:019 87c got 244 bytes
18:09:29:019 87c buf: {"result":["0xfbd42bf89ae4b0bdffdafa7c9ac7842b0cb13b4745f4cd3ea6c81e62c1617595","0xb0a52850ea22f7b03f44593e27552c6d850e40a9f6b92fbf1d15586b6affbccb","0x0000000225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"],"jsonrpc":"2.0","id":0}
18:09:29:019 87c parse packet: 242
18:09:29:019 87c ETH: job changed
18:09:29:019 87c new buf size: 0
18:09:29:020 87c DevFee: ETH: 12/30/16-18:09:29 - New job from eth-eu.dwarfpool.com:8008
18:09:29:020 87c target: 0x0000000225c17d04
18:09:29:266 804 recv: 51
18:09:29:266 804 srv pck: 50
18:09:29:292 804 srv bs: 0
18:09:29:292 804 sent: 182
18:09:29:557 13a8 GPU0 t=62C fan=35%, GPU1 t=60C fan=34%, GPU2 t=75C fan=34%, GPU3 t=70C fan=35%
18:09:29:558 13a8 em hbt: 0, fm hbt: 0,
18:09:29:558 13a8 watchdog - thread 0, hb time 7391
18:09:29:558 13a8 watchdog - thread 1, hb time 7219
18:09:29:558 13a8 watchdog - thread 2, hb time 7344
18:09:29:558 13a8 watchdog - thread 3, hb time 7172
18:09:29:558 13a8 watchdog - thread 4, hb time 7219
18:09:29:558 13a8 watchdog - thread 5, hb time 7375
18:09:29:558 13a8 watchdog - thread 6, hb time 7172
18:09:29:558 13a8 watchdog - thread 7, hb time 7375
18:09:31:596 8e0 GPU 2 DAG creation time - 7566 ms
18:09:31:596 8e0 Setting DAG epoch #96 for GPU #2 done
18:09:31:596 8e0 DevFee: restart timer because of updating DAG
18:09:31:607 924 GPU 3 DAG creation time - 7564 ms
18:09:31:608 924 Setting DAG epoch #96 for GPU #3 done
18:09:31:609 924 DevFee: restart timer because of updating DAG
18:09:31:643 a78 GPU 1 DAG creation time - 7609 ms
18:09:31:643 a78 Setting DAG epoch #96 for GPU #1 done
18:09:31:644 a78 DevFee: restart timer because of updating DAG
18:09:31:782 344 GPU 0 DAG creation time - 7634 ms
18:09:31:782 344 Setting DAG epoch #96 for GPU #0 done
18:09:31:783 344 DevFee: restart timer because of updating DAG
18:09:32:166 87c DevFee: ETH: checking pool connection...
18:09:32:166 87c send: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
18:09:32:301 87c got 244 bytes
18:09:32:301 87c buf: {"result":["0xfbd42bf89ae4b0bdffdafa7c9ac7842b0cb13b4745f4cd3ea6c81e62c1617595","0xb0a52850ea22f7b03f44593e27552c6d850e40a9f6b92fbf1d15586b6affbccb","0x0000000225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"],"jsonrpc":"2.0","id":3}
18:09:32:301 87c parse packet: 242
18:09:32:301 87c ETH: job is the same
18:09:32:301 87c new buf size: 0 2 Gig video card? Nope.. Its happening to my RX480s on all 3 rigs at the same time. You mine not ETH, but some fork. By default, miner mines ETH in devfee mode, so it has to re-build DAG because ETH and your coin use different epochs. If you mine EXP, use "-allcoins exp". If you mine ETC - you can use pools that accept wallet address directly (i.e. pools that work without "-allpools 1" option). If you mine some different coin, there is no way to fix it and you will lose about 10-15 seconds every hour for DAG recreation. If your GPU is 2GB and it cannot handle ETH DAG - it will crash. It your cards can mine ETH properly - try "-allcoins -1" so miner can detect correct DAG size at once (read Readme for details). |
|
|
|
|
Hmm, it seems 390X can reach 400H/s though it requires some additional efforts, Polaris cards can get some speedup too.
|
|
|
|
Please allow workernames as username, not only wallet addresses
bumping this once more  Ok I will release new version in 2-4 days, I will update many things. |
|
|
|
claymore, my 8g rx480 shows memory usage of 60% and GPU usage of 100% with drops to 0% several times a minute. Do you think it might take another thread?
GPU and memory are busy completely, you can check it by starting two miner instances, you will not get more speed. Due to PoW implementation, GPU cannot utilize all its resources, so you don't see 100%. what is the reason why my hashrate drops
i have mixed gpu
2x280x = 220 each
2x480 ref =210 - drops to 185
1x470 black ed - 209
Probably the reason is drivers, miner compiled with 15.12 and 16.11.3. |
|
|
|
NOTE: v9.3 is not performance release, in this version I improved compatibility/stability in GPU code and fixed Linux-related issues. You can use older versions if they are good and stable for you. thank you!
@claymore:
"- added support for round robin DNS"
I'm not a network specialist, so I ask what that means and why is that feature good for us?
I red about round robin but I didn't find the answer. Sorry if it's a dummy question.
In theory, pools can balance servers load with this feature. Nicehash pool asked me about this feature so I added it. If a pool has several IPs and first IP fails, miner will try to connect to the second IP, etc. Claymore, Is there any room for further hash improvement for RX cards or that's it?
I think it's possible to get better speed, but not too much. |
|
|
|
Only 235 - Rx 480 nitro on v9.3 On v9.2 -257  I see same hashrate 235H/s on stock RX480 on both v9.2 and v9.3, drivers 16.11.3. |
|
|
|
|
v9.3:
- improved stability and compatibility with various drivers.
- slightly improved mining speed for some cards (1-2%). About 340H/s on stock 390X.
- fixed issue in Linux version with GPU SEGFAULT and high CPU load.
- added support for round robin DNS.
- some bug fixes and minor improvements.
|
|
|
|
Claymore, the miner is not working correctly with ZCL. Whenever I try to mine ZClassic, it mines for a few minutes but as soon as the DevFee round comes, it tries to connect with the dev pool but at last, the mining almost stops.
Is there any solution for this?
You did not explain what happens exactly. Does it fail to connect? Why? PM me your command line (or config.txt if you use it) and also you can send me log file. |
|
|
|
See, I know what I'm talking about when it comes to law, while you don't. I've taken the LSAT and been in court many times, so I actually know how the law works. Just putting something in your license terms doesn't make it legally binding; the terms have to be lawful. I'm not the only one that can ignore the reverse engineering restrictions in your license; anyone in one of the many countries that allow fair use reverse engineering can. If it wasn't legal to disassemble your miner code, then it would be very difficult to detect when you violate copyright law. Since disassembling your code was important in proving you copied some of Marc Bevand's code, your response has been to point blame at those doing the disassembly. The respectable thing to do would've been to admit you screwed up, and invite people to continue to dissassemble/reverse engineer your code to confirm that you are not illegally copying other people's code in the future.
When it comes to license restrictions regarding copying like the MIT license, it is valid and legally binding throughout most of the world. There are only a few failed states that have no copyright law where MIT license would have no legal effect.
You're also showing how touchy/emotional you are. There's nothing to your miner that I, Wolf, or most other developers don't already know. You are almost paranoid about people learning how your code works, yet it's been over a month since I publicly described how to implement a ZEC miner that is significantly faster than yours. Your eth miner isn't the fastest one either; I've seen convincing evidence that Wolf's private miner is at least 5% faster than yours on some targets like Hawaii and Pitcairn.
I'm probably wasting my keystrokes since you seem unable to be unable to have a calm and rational discussion. People like Wolf earn people's respect not just from their coding abilities, but also because they don't take themselves too seriously.
If you think that you may ignore the license and disassemble miner - do it, I only note that you violate the license, that's completely enough for me. Of course you can disassemble miner privately and alarm if you find any violations, instead, you discuss your "skills" in public. If you think it's good - do it, probably it's the reason of your many courts. So learn my kernels, may be you will finally create something really fast instead of describing "significantly faster" miners and dumping kernels. I don't take it too seriously  |
|
|
|
Yeah - I've unpacked the real miner binary (zecminer64 is only 66k, this is because it loads Data3.bin, decodes it, and then runs it.)
From there you end up with a binary that looks to have been packed by a modified version of UPX - unpacking what it drops looks like an ELF loaded at 0x80000 - it patches several jumps in it to make it work, because it looks like it expects to be loaded at 0x40000. THAT looks like it drops ld.so and the real miner ELF into memory.
Yo dawg, I herd you like executing, so I put an ELF64 in your ELF64 so you can execute while you execute.
I think now one of my points about Linux release is clear - other devs want to see how my miner works and do reverse engineering as soon as they can. It's much easier to do it in Linux. My License.txt prohibits such things clearly, so you violate the license. Remember I violated MIT license in past and was blamed that I steal other's work. Now I see same thing from you. Have fun... Maybe you don't have such a sense of humor... You also don't seem to understand how copyright law works. It restricts copying, not reverse engineering. It seems you should learn a bit. The License file is a part of miner package. Besides copyrights, it also describes what you may do and what you may not. Do you state that you may ignore "License.txt"? If so, that's what I mean when I say that some devs don't respect licenses. |
|
|
|
Hello Claymore , could you add dynamic control of intensity from working miner for example by "shift +" "shift -" hotkeys ?
It would require reallocating GPU memory which will cause crash after few iterations, so I wouldn't like to do it. Why do you need it? |
|
|
|
This problem begins with 9.2. Gpu0 always hangs. I tried with default speeds and voltage but nothing changed. Log is full with ''a20 ADL: Cannot find any AMD adapters'' All my 3 rigs have same problem. with 9.0 everything is ok.
"ADL: Cannot find any AMD adapters" is not reason. Also same message must be in v9.0. It must be driver-related problem if ADL library sees no adapters. ADL library is a part of AMD drivers and related to temperature/fan management. |
|
|
|
@Claymore I got the same error in my 3 rig ith 9.2. Gpu0 hangs in all rigs. If I disable gpu0 in all rigs everything is stable. This problem doesn't exist in old releases. System asrock h81 btc pro + 6 X rx 470 nitro 8gb + 8 gb ram + ssd + evga 1300 g2 + celeron cpu win 8.1
In a couple of days I'll release an update with a bug fix for Polaris cards, though I'm not sure if it's related to the problem you describe. |
|
|
|
Actually, it would have been easier to reconstruct the actual miner binary on Windows. There's nice tools to do this for the PE32+ (PE 64-bit) format, but jack shit for ELF64.
My owner and I recovered the binary in its original, unpacked form, btw - not much in the way of anti-debugging once you get to there. Some obfuscation, but not much. Checkmate - that was a fun workout; time to figure out something else to do.
Stop worrying about your devfee, it's not about removing it or altering it. It was just fun to do.
Yeah, you and your owner did it just for fun, I understand it of course Clay you can rest assured that every big(er) cloud hashing company has your miner variations and optimizations already - regardless of ssl, packing, upx, linux etc.. Agreed. I know what I do. However, I'd like to state that some devs don't respect the license and discuss their success in miner disassembling and GPU kernels dumping right in my thread. |
|
|
|
Just noticed Claymore has a sense of humor: When setting AMD_OCL_BUILD_OPTIONS_APPEND Setting AMD_OCL_BUILD_OPTIONS gets: However after a quick hex edit of the amd opencl shared library export AMD_OCL_RALPH_OPTIONS_APPEND=-save-temps
Works just great. :-) Yeah - I've unpacked the real miner binary (zecminer64 is only 66k, this is because it loads Data3.bin, decodes it, and then runs it.) From there you end up with a binary that looks to have been packed by a modified version of UPX - unpacking what it drops looks like an ELF loaded at 0x80000 - it patches several jumps in it to make it work, because it looks like it expects to be loaded at 0x40000. THAT looks like it drops ld.so and the real miner ELF into memory. Yo dawg, I herd you like executing, so I put an ELF64 in your ELF64 so you can execute while you execute. I think now one of my points about Linux release is clear - other devs want to see how my miner works and do reverse engineering as soon as they can. It's much easier to do it in Linux. My License.txt prohibits such things clearly, so you violate the license. Remember I violated MIT license in past and was blamed that I steal other's work. Now I see same thing from you. Have fun... |
|
|
|
I m reading every single comment in the thread and i also read yout post 40 day ago.
NVidia: if I release miner for NVidia, these haters will again say that I stole SA engine. So there will not be NVidia version.
I think other devs will create public miners with similar speed for Linux and NVidia soon.
But this doesnt matter, if you think this is ok so keep doing it. No one can tell you what to do or what not its your choice.
You forgot to quote this: It's not about money, there are several reasons why I'm not going to release ZCash miner for Linux in near future - most of haters who say that I stole SA engine are on Linux so let's they use some different miner. Also I don't like to see as someone applies IDA to my miner to see how it works. Also I don't like Linux, it's a pain for me.
So you can see that I did not say that I will never release Linux version again, I only said I won't do it "in near future" and it was >40 days ago. Though I clearly mentioned that there will not be Nvidia version. |
|
|
|
Hahahahaha linux version. Before saying he will never suport linux because he dont like the linux haters and now what? I cant stop laughing for real. Well finaly the money is more important than the dignity. Happy holidays xdd
Here is my original message (>40 days ago), please read it carefully: https://bitcointalk.org/index.php?topic=1670733.msg16836757#msg16836757Key word is "near future". anyone know what this means
20:18:10:261 904 Frontend phase failed compilation.
Error: Compilation from LLVMIR binary to IL text failed!
20:18:10:261 904 16x binary failed, try 15x
cheers
This is not critical error, so don't worry. Miner tries different binaries to select the best, if you use 15.x drivers then attempt to load 16.x binary will cause this message. |
|
|
|
With 9.2 - 370 h/s. Thats cool.
Only one question remains - how? All is stock.
Most of shares will be rejected: GPU does not work properly. It must be drivers if you use stock clocks, try different drivers. In next update I will improve compatibility. |
|
|
|
FINALLY a LINUX build!!!!! Thank you Claymore! Thank you, Thank you, Thank you!
I have it up and running on a Linux rig now and a very nice improvement over my Silent Army miner. The was so sorely needed. ZEC mining was a weak spot because I couldn't get the hash rates out of my Linux rigs. This is wonderful news. So far it looks good!
UPDATE: I may have spoke too soon... Just got a watchdog and having to reboot a miner...
Make sure you use stock clocks for first tests. Currently I can only confirm issue with gpu-pro drivers that causes a lot of messages to syslog (and therefore high CPU load on multi-GPU systems), I'm working on it. |
|
|
|
|
Show Posts
