Claymore - Would it be possible to have the logs go into a subfolder in the next version?
+ Or you could take a look at the readme and use "-logfile logs/logfile.txt"  Yes, also in next update I will improve "-logfile" option so you can specify folder for logs if last character is slash, for example "-logfile logs\". |
|
|
|
As I understand a stale share is a share which was sent to the pool by another miner before yours sent it. So your miner sent a share which already was accepted by the pool. When you know this you understand why only the pool knows which share is stale is and which isn't.
When two miners send same share it's called a duplicate share. Stale share is a share that is sent too late, when pool is already working on new block. Don't you want to add a new option into your miner: to set epools.txt (dpools.txt) files as options in command line or in config.txt file. That will let user to launch just different bat-files when switching to another coin without making each time changes in epools(dpools)-files for new alternative pools.
Ok, I will add it in next update. |
|
|
|
Hey guys,
I still have a number of stale shares on ethermine.org whilst using v11.5. To give you an idea, I regularly get over 10% stale shares. I mine with 2 x GTX 1050ti, 1 x rx470 and 1 x rx480.
So onto the question, Claymore, is it possible to log what gpu is submitting the stale share?
No, because pool doesn't notify miner that the share is stale, you can only see it on pool dashboard Really?! So how does this option works, if miner does not know about stale shares: -estale send Ethereum stale shares to pool, it can increase effective hashrate a bit. Default value is "1", set "-estale 0" if you don't want to send stale shares. Pool sees different rate of stale shares than miner, it's always higher, so I don't see any reason to show stale shares rate of the miner, it's quite low. However, due to some delays on pool and also network delays, pool always will get more stale shares than miner knows. The only way to get the pool stale shares rate is to get appropriate response from pool, but pool does not notify miner that the share is stale. To understand it deeply you should learn how pool mining works in details. |
|
|
|
I'm still on the 10.6 version, which gives me over 196mhs on my 13 rx560 cards (using linux/hiveos).
From the 11.x version, I lost about 0.800 per card, which means that I lost a big 10mhs for my rig.
Using the 11.4 version, things got a little bit better, but still under 10.6 version. With this version I got 194mhs.
Not tested yet the 11.5 version, but probably the -oldkernels switch will bring me back the best performance I had with claymore.
that is right. But the stale share is less. So you might end more valid shares. I have similar hashrate for v10.6 and v11.5, but you can try "-oldkernels 1" if you see bad speed. Also you can try "-asm 2" and "z" key to find best -dcri for ETH-only mode. |
|
|
|
Let me make it straight.
His miner is fast indeed, but it's proprietary Windows only with a dev fee. Considering size of the NeoScrypt mining market, it could make him a few bitcents daily. On the other hand, NSGminer is open source and therefore funded entirely by user donations. There haven't been any for the last year despite a dramatic increase in mining profitability. You can check yourself with the donation addresses in the OP. I could assume the people don't care about mining performance, but this thread's activity suggests the opposite. If all those miners don't bother themselves to donate anything, why should I bother myself to write faster kernels to please them?
If I don't get 0.15 BTC in donations to cover the cost of a single decent Vega 64 card for development purposes, I'll be greatly discouraged to upgrade the performance of NSGminer to match Claymore's one.
Some people like to complain about greedy developers if they use devfee, but same people don't want to donate even single day of mining for all efforts that were put into mining software. I donated 0.15BTC, it's devfee from my NeoScrypt miner for about two weeks. BTW, be ready to spend a lot of time if you want to speed up your miner on AMD, I spent more time than I expected... |
|
|
|
Should I stick with v11.4 with my Nvidia rig?
If you have enough rigs to see good average stats you will notice about 1% less stale shares in v11.5 on nvidia. |
|
|
|
v11.5:
- added "-oldkernels" option (AMD GPUs only), you can try "-oldkernels 1" to use old-style GPU kernels from v10, they can be more stable for hard OC and custom BIOSes.
- a bit reduced stale shares for Nvidia GPUs.
is there a conflict if i have -asm 2 along with -oldkernels 1? No conflicts. -oldkernels selects source of binaries, -asm selects binary. |
|
|
|
|
Let me explain: some people apply OC and memory straps to get best hashrate. They spend a lot of time to find best values, and finally it works. But it works only for some specific GPU kernel, it may fail as soon as you try to start some different miner or even same miner but with updated GPU kernel. After that you can blame the miner of course, but the reason is in your settings, you need to readjust them for new kernel.
I added "-oldkernels 1" option so now you can use old kernels in latest version, hope it will help.
|
|
|
|
|
v11.5:
- added "-oldkernels" option (AMD GPUs only), you can try "-oldkernels 1" to use old-style GPU kernels from v10, they can be more stable for hard OC and custom BIOSes.
- a bit reduced stale shares for Nvidia GPUs.
|
|
|
|
I see some people have problems with latest versions because they use hard OC and/or custom bioses created for old versions. They work fine with old GPU kernels, but I modified kernels in v11.2 and you need to readjust your settings.
For those who cannot do it (or don't want to do it) I can revert some changes and release a version with "old-style" binaries. So I will release v11.5 within a few hours and it will be the only change in this version, so don't upgrade if v11.4 works fine for you.
@Claymore, can you please name the modified Version with old Kernelīs like 11.4(old) and not 11.5? I think this would be better than 11.5. Some Miners auto update to the newest Version and with the old Settings it might be a step back for miners with readjustet settings. Thank you for your good work! 11.4 works fine for me, <4% stale (with WIFI), no crashes, stable with adjusted settings Oliver Two v11.4 would make a mess. I will add a notice to History.txt and OP about v11.5, I hope most people read it  I see stable 2% of stale shares for both ETH-only and dual modes for AMD cards, a bit more for Nvidia. |
|
|
|
I see some people have problems with latest versions because they use hard OC and/or custom bioses created for old versions. They work fine with old GPU kernels, but I modified kernels in v11.2 and you need to readjust your settings.
For those who cannot do it (or don't want to do it) I can revert some changes and release a version with "old-style" binaries. So I will release v11.5 within a few hours and it will be the only change in this version, so don't upgrade if v11.4 works fine for you.
does it mean 11.5 will have issue with stale shares again? I like 3% stale instead of 8% for 11.1, but a couple of rigs began very rare crashing since updating to 11.2. No, stale shares will be same as for 11.4 (i.e. almost zero) because it is not related to GPU kernels directly. |
|
|
|
|
I see some people have problems with latest versions because they use hard OC and/or custom bioses created for old versions. They work fine with old GPU kernels, but I modified kernels in v11.2 and you need to readjust your settings.
For those who cannot do it (or don't want to do it) I can revert some changes and release a version with "old-style" binaries. So I will release v11.5 within a few hours and it will be the only change in this version, so don't upgrade if v11.4 works fine for you.
|
|
|
|
It needs more ram to get the things going. What's the problem?
some hours to get what? And? for example, one rig didn't lower ram usage even after 40 hours. All rigs a totally equal, so smth is wrong, I think Everything is ok. |
|
|
|
@Claymore
tested the 11.4 for 10 hours on my 8 GPU rigs splitted in 2 instances:
- 4 dual GPUs, incorrect shares 3,27%
- 4 solo GPUs, incorrect shares 0%
Is there something wrong again? Giving the situation no point in doing dual...
Good news is that stale was 3.1% ;-)
Thanks
Stale shares rate must be the same for both ETH-only and dual modes, in my tests it's 1-2%. |
|
|
|
@Claymore
Since upgrading from 10.6 to 11.3 (and now 11.4) my hawaii rigs are having hash rate drops every so often. About 5-7% drop lasting for around 2 minutes before going back to normal for about 10-15 minutes before it happens again. Any idea what might be going on?
I don't see this issue on my test 390X card. You can try to change -dcri to see if it helps. Also you can PM me the log file, I will check it. |
|
|
|
|
Uploaded, so again:
v11.4:
- fixed issue with stale shares.
- fixed issue with incorrect shares.
- a few minor bug fixes and improvements.
This is highly recommended update.
|
|
|
|
|
I will upload v11.4 within an hour.
|
|
|
|
|
This time I want to be sure that it works 100% stable so please wait a few hours, I will upload files as soon as I confirm that it's good.
|
|
|
|
|
v11.4:
- fixed issue with stale shares.
- fixed issue with incorrect shares.
- a few minor bug fixes and improvements.
This is highly recommended update.
|
|
|
|
Dear @Claymore,
I have noticed increase in stale shares from 11.2 to 11.3 about 3%. Nothing is changed beside the version of the miner. Can you check that?
What pool do you use? us1.ethermine.org:14444, like before I see some crazy values for stales today, up to 15%, it can be some issue on pool side. Try to start v11.2 and see if it helps. |
|
|
|
|
Show Posts
