NiceHashMiner-Archived
NiceHashMiner-Archived copied to clipboard
nicehash
Webstats not matching GUI or CLI stats - not being compensated for hashing power
I am currently troubleshooting an issue with 2x RX 470s. I am running 17.2.1 drivers. I have tried using 16.11.5 drivers and had the same issue.
No matter what drivers I use or which benchmark I perform, I still get the same issue. My CLI and GUI will say I'm hashing at 40MH/s and should be making approximately $3+USD/day, but when I check webstats it fluctuates all over the place from 3 MH/s to <20MH/s. I thought maybe your webstats just took a long time to update properly, so I left it running for 12+ hours, but the total balance earned is still less than $1.
I tried contacting support, but all they did was tell me to use the older drivers which provided the same issue and made things worse. Sometimes the cards would drop from 40+ MH/s to 0 for a minute and then pop back up.
@electricmoose there could be a few issues that you could try to address:
-
Try running NiceHash Miner in GPU-mode only (un-check / disable CPU)
-
Make sure you have stable internet connection to our locations (take a look at this FAQ: https://www.nicehash.com/index.jsp?p=faq#faqs13
-
Try using claymore option for DaggerHashimoto as well as CrpytoNight algorithms for your GPUs (you can set this under Benchmarking options).
@kenshirothefist This has been an issue for over few months. NOTHING from those 3 steps fixes this. Stats in web always are either low or way too high but NEVER match. Rarely few times a day mBTC match but even those are lagging. No concrete solution has ever been provided and threads are closed just like that. :-1:
I've tried 1 and 2. Neither have helped
In response to 1: I have tried disabling CPU and I have tried running only 1 GPU, neither attempts result in accurate hashes or compensation. While I was able to get a semi-consistent 20MH/s when CPU was disabled, my GUI and CLI still reports 40MH/s. With running only 1 GPU, it seems I am only receiving 3-<10MH/s and it is erratic. It seems that no matter what I do that at best I am only receiving 50% compensation for my hashing power. I have included some screenshots below.
In response to 2: I have 0% packet loss with all 4 servers. US: < 60ms EU: < 100ms HK: <200ms JP: <200ms
I have not attempted to use the claymore miner because I am not comfortable with running closed source on my machine. If I had to do that, I would set everything else up in a different way and take my hashing power somewhere else...
I have the same issue with all the cards I use (GTX 1080, GTX 1070, GTX 1060, RX 480, and RX 470). In 90% of the time accepted hash rate is lower (or significantly lower) than the hash rate reported by the client. During the last few days there is very big difference for Nvidia cards.
Mine were mining Lyra2rev2 and showing about half of the clients reported rate most of the time.
I am having the same problem. I am almost certain it isn't a software or hardware problem, but a server side issue with Nicehash. I am using a baikal giant which runs at a constant 918Mh/s but the web stats shows around 600mh/s most of the time. It started about a week and a half ago. Never had this issue before. Maybe Nicehash is being targeted by ip attacks?
@nicehashdev GTX 1080 was mining Lyra2rev2 most of the time, GTX 1060 - Equihash most of the time, GTX 1070 both Lyra2rev2 and Equihash.
It is possible that ccminer isn't following stratum specs correctly regarding diff adjustments. I noticed that in my tests.
Excavator should not have this behaviour.
Anyway, we are working on getting all popular algorithms into excavator so issues like that should not happen.
As for other hardware and ASICs - contact producer of your hardware and let them know that stratum specifications need to be followed fully if your mining hardware is to hash with full speed.
@nicehashdev So if I understand you correctly rate reported by the client has nothing to do whit what nicehash will decide to pay me. My client may show 28 Mh/s (sgminer and RX 480) but you can pay me only 10 Mh/s with the explanation that maybe the client (that is part of your distribution) is buggy.
My ASIC Was Working Perfectly A Couple of days Ago. This All Started When Your Servers Went Offline For A Couple Of Hours. Now Onlt Certain Times Of The Day It Reports speed Properly. It Used To Get Constant Between 850mh/s And 900mh/s. Now I Get 600 To 700
@nicehashdev BTW switching from sgminer to claymore (for DaggerHashimoto with RX 480 and RX 470) does not change anything. Still accepted speed (reported by web interface) is lower or much lower than speed reported by the client. Unfortunately the same is true for the actual payout - it is lower than advertised. I am also curious how you do benchmarking. Because if it is based on the local client results it is very misleading (to say it in a soft way). My RX 480 is benchmarked at 27.8 Mh/s (and I suppose your software uses this value when deciding about switching the algorithms) but you accept (and pay me) only 10-20 Mh/s. If for some of the other algorithms (Equihash for example) for some reasons you accept all of my hashing power it could be more profitable for me to use it (even if it is benchmarked lower). What I am trying to say is that if the benchmarks are based on local client results they are meaningless because actual payment has nothing to do with it.
My Asic mines at full speed. Constant 918Mh/s. The web interface reports this as if it fluctuates between 600 and 750mh/s. I have tried on zpool and it reports speed properly, so I don't think it is an issue on my side.
Updated to 1.7.5.9 and used a 970 GTX, and now my web stats appear to accurately reflect my GUI. Not sure if it's the new version or me using an nvidia card that fixed it. I'll be setting up another rig with those RX 470s I was originally using, and will test to see if the new version has fixed the problem. Otherwise, I think I'm going to have to try another pool.
Let me clarify my previous statement a little bit. They do not accurately reflect stats at all time, but are more accurate than before.
My guess is that NiceHash's servers are having trouble accepting the volume of traffic.
+1 I have also noticed the discrepancies between the web and GUI. Hopefully we can get a better explanation or hopefully a fix soon.
Hello, I have exactly the same problem with DaggerHashimoto, i'm using Claymore's Dual Miner v9.3 with 5 rx480, my hashrate in the console is stable, around 133Mh/s, but in the nicehash status page, hashrate is most of time lower, and never stable, changing between 80 and 130 Mh/s. Thank you if you can fix this, i think a lot of people will use another pool if we loose 40% of hashrate.
If you are getting these hashrate fluctuations with closed source fee miners such as claymore, have you considered fee mining? Do not forget about that fact. If you do not wish to use fee based miners such as claymore, use sgminer.
It has nothing to do with fee or non fee based miners. This issue has been plagued since last year. Irrespective of which miner is used the stats DO NOT MATCH. I am sure people will post proofs of this after my post.
We have several test rigs running and did not notice this.
True, there was a period when AMD had issues - no shares were being found or sent. But to my knowledge, these issues were fixed.
@all: We did extensive testing and the reported issues are isolated issues, not a generally present issue. In order to debug this issue furthermore we'll need some more information from you. All of you that are having issues with supposedly web-recorded speed lower than miner-reported speed please submit the following information:
-
Go to your Miner's page (https://www.nicehash.com/?p=miners&addr=YOUR-BTC-ADDRESS), click on your algorithm in the "Algorithms" table. Then scroll down to the "Interactive history" graph which shows "Average speed (and payrate) for selected timespan", select "All" for the time span. Make screen-shot of this graph and mark it with the algorithm that it belongs to.
-
Make screen-shot of the running miner, used to mine the same algorithm as the graph is showing.
-
Write down additional information: your GPUs/devices, your OS version, drivers version, location used for mining (EU, USA, HK, JP).
Submit all this info here as a new comment to this issue.
Thank you for your feedback.
Eth only mode
- GPU: 2 Rx 480 MSI Gaming X 8 GB OS : Windows 7 Ultimate 64 bit Driver: 16.9.1 Location for mining: EU
@nerdatwork thank you for your feedback. Could you also please post your results in ethereum-only mode (not using dual-mining)?
@nerdatwork these warnings "GPU #0 got incorrect share" could be the root cause of these issues. I suggest you to run only on GPU #1 (you have to verify if NHM GPU numbering is the same as EthDcrMiner64 GPU numbering - it might be vice versa) for at least 30 minutes on Ethereum mode only and then check online graphs if speed matches.
Trust me it's not related to that. Even with ethminer I got same issue of non matching stats. ANY miner used sgminer, ethminer, claymore's miner. Stats do not match.
Try posting a poll on the webstats page and ask your miners question like this with YES or NO option Q: Are your webstats matching exactly with GUI miner stats at all times ?
@nerdatwork But did you try running with only one GPU active? It just might be that something is foobar with one of the GPUs.
Yes I have tried with 1 GPU and it is still the same. I hope others can post feedback soon.
I am still in the process of collecting feedback/details and some undeclinable proves. I see this happen every day. It's like a short delay coming from the web backend. Especially I discover this after the mining algorithm was changed. Is this just a delay in the refreshing of the statistics which however will be compensated and therefore credited or is it a real performance fluctuation which will result in lower credited balances?
Some valid statements from NH on this situation would be great!
Like I said before:
It is possible that ccminer isn't following stratum specs correctly regarding diff adjustments. I noticed that in my tests.
It is clearly possible, that other mining sws have same issue. The only sw that we can confirm doesn't have this issue is our own miner - excavator.
As for the exact possible scenario is this. If the miner does not follow stratum protocol correctly, when pool sends diff adjustment, miner starts using that new diff immediatelly, which is wrong and not correct according to stratum specifications. New diff is enforced with NEXT job. Now, NiceHash does follow stratum specs correctly and considers that after sending diff adjustment to some high diff, you are still allowed to send low diff shares. But your mining sw stops sending low diff shares - it is only sending high diff shares - thus the speed on web shows as being reduced.