Hello this morning I had an error that I had never before, what do you mean by this error?
Error occurred somewhere before your piece of log. |
|
|
|
to Claymore
Dear Claymore.
Nicehash Ethereum + Decred:
EthDcrMiner64.exe -epool stratum + tcp: //daggerhashimoto.eu.nicehash.com: 3353 -ewal 1LmMNkiEvjapn5PRY8A9wypcWJveRrRGWr -epsw x -esm 3 -allpools 1 -estale 0 -dpool stratum + tcp: //decred.eu.nicehash.com : 3354-dwal 1LmMNkiEvjapn5PRY8A9wypcWJveRrRGWr
Permanently go rejected DCR, I'm ready to pay a commission, I support it, but please, modify (correct), the version of the miner
Nicehash has own stratum specifications for most coins, that's the reason. Yes I will check it and include in next update, I'm not sure if it's a good idea to release new version just with Nicehash DCR fix. Currently I'm working on assembler kernels, they will be ready in a few days. |
|
|
|
@claymore Using Nicehash miner's Claymore dual miner gives 15% to 20% rejected shares on second coin. Any way to fix this ?
You can try to change pool. Hello Claymore, Having issue with connecting to "devfee" pools past few days. Mining continues for about 2 hours and stops so I have to restart miner or use "nofee" option. "-allpools 1" wont help too. Any words of wisdom?  The best solution is to change your ISP if all devfee pools fail for you, also use pool that accepts wallet address directly so miner can use same pool for devfee mining. |
|
|
|
But I mean when the pool disconnects me, in many occasions it sends Many invalid shared and disconnect me and reconnect to the seconds, here I leave an example in the log
Bug confirmed, miner ignores "-retrydelay" option when it disconnects due to pool errors. I will fix it in next update. |
|
|
|
Friends, there is some command or some configuration where I can close the Claymore automatically when it is disconnected because there is no way to send new jobs or many invalid shares have been sent (Miner disconnects automatically if pool does not send new jobs for a long time or if pool rejects too many shares) I need that when the claymore is disconnected for any of these reasons, the program will close automatically
From OP or Readme: -retrydelay
delay, in seconds, between connection attempts. Default values is "20". Specify "-retrydelay -1" if you don't need reconnection, in this mode miner will exit if connection is lost.
|
|
|
|
Currently I don't plan to add it. 12:30:30:451 141c socket was closed remotely
12:30:30:451 141c ETH: Connection lost, retry in 5 sec... What does it mean? -mport is disabled Thanks! It means that connection to the pool was closed remotely, i.e. by pool. |
|
|
|
v12.4:
- slightly improved speed for some cards (1-2%).
- added "-gmap" option.
- a few minor changes/improvements.
Perhaps 1% improvement on 470, hard to tell, bout 299 sol/s avg on 470 8gb, bios mod Not all cards got speedup. My tests show most speedup for Tonga cards, some Hawaii cards, but speedup is minor anyway. |
|
|
|
|
v12.4:
- slightly improved speed for some cards (1-2%).
- added "-gmap" option.
- a few minor changes/improvements.
|
|
|
|
|
In 1-2 days I will release new version, a bit faster and stable.
|
|
|
|
Claymore, do you have any plans to improve you CPU miner ?
Currently I don't have time for it  I'm working on ETH and ZEC miners. |
|
|
|
|
v8.1:
- added Ethereum+Pascal mode for NVidia cards.
- improved "-di detect" option: now after GPU order detection miner starts mining with the detected order.
- now remote management is working in read-only mode by default.
- improved "-mport" option, now you can specify network adapter IP for incoming connections for remote management.
- added "-benchmark" option.
- fixed issue with "-retrydelay" option.
- added "-v" option.
- a few minor bug fixes and improvements.
- EthMan: added option for font color selection.
|
|
|
|
Hey guys, would appreciate an honest answer here please.
I was about to buy a few RX 470 8GB cards to mine either zcash or ETH but have been hearing about these new cards about to be released....Will there be a massive difference in speed from the 470/480s compared to these new cards?
I dont want to build a rig that gets me 1800 - 2100H/s then get blown away by a new miner with new cards that gets double + speeds..
I remember claymore mentioning that he cant do much because of the following..
Memory bandwidth:
RX480: 256 GB/s
If these new cards have the same bandwidth then does that mean no real big speed improvement?
Thanks.
Would like to know more about it too, maybe Claymore can explain this to us. Claymore please, we need your attention here! I cannot comment unreleased cards. Changes in hardware can improve or kill speed on such complex PoW as ZEC, there is no way to know until real tests. |
|
|
|
Hello,
I have 2 Nano, 1 R9 280x and 1 RX480, is there a driver version where i can mix them and use -asm 1 for all cards?
if i use 15.12 i can not use RX480
if i use 16.12.2 i can not user nano with -asm 1
Thank you
No. Either split cards to different rigs, or use Linux version (but amd-pro drivers don't support 280x). |
|
|
|
The memory leak must have to do with PAS before I started to mine PAS I did not have the issue but at 13GB memory of usage when I have 16GB memory the miner kept mining but would not actually send out the hash data. At that point I had to restart it. So probably in the PAS routine.
Glad to hear a new update will be released though soon.
Ask if someone has same issue, I don't see any memory leaks in ETH+Pascal mode. |
|
|
|
It appears that 8.0 has a severe memory leak. The miner reached 13GB of memory usage. This is no small leak that is a major leak. When it got that heavy it stopped sending out hashing power even though it was mining the remote manager said it had no hash power.
This is a well-known issue. Within a few days of launch Claymore released a new 8.0 which fixed the memory leak. Perhaps he should have called it 8.01 or something so people would know that it fixed a problem. It was ZEC miner v12.2, not this miner. ETH v8.0 miner has no known memory leaks and I did not release any updates for it. Though in 1-2 days I will release new version with Pascal support for NVidia and some other improvements. |
|
|
|
Issues with Version 12.3:
- Some rigs will not run all GPUs since v12.0. With 12.0 and later, some GPUs report 0.00H/s rate. One of rigs has 7990, only uses one core. Have not tried 12.3 version on this unit, it runs 12.0 fine.
- Option -di detect will run very long time on a couple rigs. Would love to know a procedure to do this manually by switching GPUs on and off. How to map default GPU order to -di GPU order? This is an issue because miner will reduce intensity on the wrong card, leaving the hot card to keep getting hotter and eventually stop or crash the rig. Does the ordering need to be recalculated for different versions?
Linux rigs seem more stable than Wndows rigs.
Thanks for a great miner.
1. Set more virtual memory, use less "-i" value. 2. Use "-di detect" only once to get indexes, then specify them in "-di" option. Use 0...9 keys to enable-disable GPUs if you want to find physical GPU from its index. GPU indexes are related to hardware/drivers only, the order is the same for all versions of all my miners because they just use OpenCL order. |
|
|
|
To all: you can see low speed at highest possible "-i" value, if so, reduce it. For example, you specify "-i 8" for 280X 3GB card, miner reduces it to "-i 7" automatically (shows "not enough GPU memory" message), but it may work much slower than "-i 6". So if you see that new version is slower than old version - try to reduce "-i" value a bit. In some cases you can increase "-i" value, for example, in my tests Nano cards work best with v12.2 using "-i 7", but for v12.3 "-i 8" is faster. @Claymore Can you make something to improve 380 series? Currently I have 210H. Too low... Thank you in advance
Tonga is really weak for ZEC. why my nano can't use -i 8? AMD Cards available: 3 GPU #0: Fiji, 4096 MB available, 56 compute units GPU #1: Fiji, 4096 MB available, 64 compute units GPU #1 recognized as Fury X/Nano GPU #2: Fiji, 4096 MB available, 64 compute units GPU #2 recognized as Fury X/Nano POOL version GPU #0 is going to use too high intensity (  , not enough GPU memory, intensity value reduced (7) GPU #0 algorithm ASM, intensity 7 GPU #1 is going to use too high intensity ( , not enough GPU memory, intensity value reduced (7) GPU #1 algorithm ASM, intensity 7 GPU #2 is going to use too high intensity ( , not enough GPU memory, intensity value reduced (7) GPU #2 algorithm ASM, intensity 7 Make sure you set these env variables: GPU_MAX_HEAP_SIZE 100 GPU_MAX_ALLOC_PERCENT 100 GPU_SINGLE_ALLOC_PERCENT 100 |
|
|
|
To all: you can see low speed at highest possible "-i" value, if so, reduce it. For example, you specify "-i 8" for 280X 3GB card, miner reduces it to "-i 7" automatically (shows "not enough GPU memory" message), but it may work much slower than "-i 6". So if you see that new version is slower than old version - try to reduce "-i" value a bit. In some cases you can increase "-i" value, for example, in my tests Nano cards work best with v12.2 using "-i 7", but for v12.3 "-i 8" is faster. @Claymore Can you make something to improve 380 series? Currently I have 210H. Too low... Thank you in advance
Tonga is really weak for ZEC.
|
|
|
|
|
v12.3:
- slightly improved speed, about 410H/s on stock 390X, 465H/s on stock Nano, 300H/s on stock 280X, 305H/s on stock RX480.
- improved stability for high "-i" option values, added "-i 9" option value.
- fixed a few bugs.
|
|
|
|
edit: I googled it and found is I wonder why it wont connect to port 33357 for the dev fee I didnt try it on my setting but will
You should ask nicehash about it. |
|
|
|
|
Show Posts
