nicehash / NiceHashMiner-Archived

NiceHash easy to use CPU&GPU Miner
843 stars 326 forks source link

Webstats not matching GUI or CLI stats - not being compensated for hashing power #789

Open electricmoose opened 7 years ago

electricmoose commented 7 years ago

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.

170411_nicehashcli 170411_nicehashgui 170411_nicehashweb

kenshirothefist commented 7 years ago

@electricmoose there could be a few issues that you could try to address:

  1. Try running NiceHash Miner in GPU-mode only (un-check / disable CPU)

  2. 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

  3. Try using claymore option for DaggerHashimoto as well as CrpytoNight algorithms for your GPUs (you can set this under Benchmarking options).

nerdatwork commented 7 years ago

@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:

electricmoose commented 7 years ago

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...

170411_202_nicehashgui 170411_202_nicehashcli 170411_202_nicehashweb 170410_1012_nicehashweb2 170411_nicehash_1gpu_gui 170411_nicehash_1gpu_cli 170411_nicehash_1gpu_web

goutevd commented 7 years ago

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.

nicehashdev commented 7 years ago

@goutevd Were your miners mining Lyra2rev2 most of the time?

Joshwaa2010 commented 7 years ago

Mine were mining Lyra2rev2 and showing about half of the clients reported rate most of the time.

Johann1982 commented 7 years ago

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?

goutevd commented 7 years ago

@nicehashdev GTX 1080 was mining Lyra2rev2 most of the time, GTX 1060 - Equihash most of the time, GTX 1070 both Lyra2rev2 and Equihash.

nicehashdev commented 7 years ago

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.

goutevd commented 7 years ago

@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.

ChriscomIT commented 7 years ago

Please fix this asap. Its a real serious issue.

Johann1982 commented 7 years ago

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

goutevd commented 7 years ago

@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.

Johann1982 commented 7 years ago

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.

electricmoose commented 7 years ago

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.

electricmoose commented 7 years ago

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.

bsjelin commented 7 years ago

+1 I have also noticed the discrepancies between the web and GUI. Hopefully we can get a better explanation or hopefully a fix soon.

eki78 commented 7 years ago

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.

nicehashdev commented 7 years ago

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.

nerdatwork commented 7 years ago

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.

nicehashdev commented 7 years ago

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.

kenshirothefist commented 7 years ago

@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:

  1. 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.

  2. Make screen-shot of the running miner, used to mine the same algorithm as the graph is showing.

  3. 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.

nerdatwork commented 7 years ago
  1. dagger eu graph

  2. dagger and pascal miner stats

    Eth only mode eth only mode

  3. GPU: 2 Rx 480 MSI Gaming X 8 GB OS : Windows 7 Ultimate 64 bit Driver: 16.9.1 Location for mining: EU

kenshirothefist commented 7 years ago

@nerdatwork thank you for your feedback. Could you also please post your results in ethereum-only mode (not using dual-mining)?

kenshirothefist commented 7 years ago

@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.

nerdatwork commented 7 years ago

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 ?

kenshirothefist commented 7 years ago

@nerdatwork But did you try running with only one GPU active? It just might be that something is foobar with one of the GPUs.

nerdatwork commented 7 years ago

Yes I have tried with 1 GPU and it is still the same. I hope others can post feedback soon.

ChriscomIT commented 7 years ago

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!

nicehashdev commented 7 years ago

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.

aidonaks commented 7 years ago

@nicehashdev

Excavator should not have this behaviour. Anyway, we are working on getting all popular algorithms into excavator so issues like that should not happen.

On @Excavator - I too have found a significant and not ignorable difference between the ~3K sols/sec my test rig (7 x GTX 1070s) shows (EDIT1: on the NHM gui) vs the 2.5k to 2.6k sols/s that the web system shows as a multi day avg. Running NHM 1.7.5.12 on Win10 here. If it's just a temporary reporting issue (few mins on web vs cumulative on NHM miner) then it's fine. But it just feels wrong, you know?

p.s. Edited 2nd time for grammar only.

nicehashdev commented 7 years ago

On @Excavator - I too have found a significant and not ignorable difference between the ~3K sols/sec my test rig (7 x GTX 1070s) shows (EDIT1: on the NHM gui) vs the 2.5k to 2.6k sols/s that the web system shows as a multi day avg. Running NHM 1.7.5.12 on Win10 here. If it's just a temporary reporting issue (few mins on web vs cumulative on NHM miner) then it's fine. But it just feels wrong, you know?

Are you sure you are mining ONLY equihash and no other algorithm?

aidonaks commented 7 years ago

@nicehashdev - I'm using only one instance of Nicehash Miner on Windows 10 and yes - at one time I'm only mining one particular algorithm - whichever one NHM chooses. I'm comparing only the stats for Equihash on web vs windows GUI.

That said...

  1. I'm only referring to the hash rate, not the mBTC.
  2. Also, I paid closer attention to the stats after making the above post a few days ago and I think that at least in case, it's just a difference in what's being measured on the NHM GUI vs the web stats. The former appears to show a longer term average and the latter obviously shows only a few minute average. I think in my case, this explains the difference. Dunno about the OP. Sorry if I caused any confusion, am only a couple of weeks only on this system so still figuring things out.
  3. Perhaps it might be a good future feature to align the methods of measurement on the web stats vs the GUI? :-)
HailHEN commented 7 years ago

@nicehashdev Windows 10 64-Bit Mining Dagger hash mainly. 1 X R9 390x (planning to install one more GTX 1070) Crimson 17.4.4 (AMD driver)

I have also found a similar issue with my miner on the latest nice hash update. I get extreme inconstancies that are noticeable on the average and on the profitability graph. I am meant to get somewhere near 31M which says it in the sgminer window, but on the nice hash website it says i get somewhere around 14M average. This is a very large difference! Whats even more irritating is that stops mining for around 5-30 minutes??? screen shot 2017-06-23 at 7 16 11 am screen shot 2017-06-23 at 7 19 05 am

screen shot 2017-06-23 at 7 24 13 am

If there is a fix I would like to hear some suggestions, it would be really helpful.

blogbytes commented 7 years ago

I am having the exact same issue. Stats on the website are erratic and are not correct. It seems it doesn't report all the hashing power which is a shame. I will provide screenshots later.

HailHEN commented 7 years ago

@blogbytes This is not fair, @nicehashdev should actually pay attention to this.

naskobulgaria commented 7 years ago

Same issue to me. Hashrate changing from 13 MH/s to 25 MH/s from time to time. Not stable at all. I use nicehash pool also.

electricmoose commented 7 years ago

I have had this issue for months now using Nicehash's pool. I've switched to other pools and have NOT had this problem, using the same miners. This is clearly a server-side issue with Nicehash.

ChriscomIT commented 7 years ago

Same here. Sadly no one cares.

naskobulgaria commented 7 years ago

Can you suggest @electricmoose some other good working pool?

daniel-schuermann commented 7 years ago

same here with RX480 reporting 27MHs in client and 7MHs on web.

ChriscomIT commented 7 years ago

Again extreme fluctuations :-( GUI and CLI show 357sols for my worker1 and webstats show 233sols. Thats a discrepancy of over 100sols. Also my payrate is very low. Much lower as always.

nicehash fluctuations
nicehashdev commented 7 years ago

There is measuring interval on web (5min). Due to high diff shares, speed will jump up or down, unless you have large hashpower. Always measure on some interval (1 hour at least, but I suggest 8+ hours). You will see that speed is about the same (+-2%).

ChriscomIT commented 7 years ago

Ok, that's what I thought/observed already in the last time. Nevertheless, even after 20h+, I see sometimes fluctuations of hashing power from the real values (positive and negative). But maybe that's related to my slightly low hashpower and the measuring interval on web. If you say thats the intended behavior and everything works fine then nothing can or must be done. Thanks for the clarification!

nicehashdev commented 7 years ago

Yes, and if using NH, you also need to consider algorithm switching. This can decrease your long term average speed, because you've been mining other algorithms in the middle.

ChriscomIT commented 7 years ago

Mhh ok and in what percentage does it differ? I know that algorithm switching reconnects the miner. But you saying me indirectly that I should better keep mining one algorithm like equihash instead of using Nicehash main feature the automatically algorithm switching for most profit? What's the purpose of using Nicehash app then or do you relate this just to the web end stats?

However there is something weird with the web backend. Even after hours of the same miner instance working (same algorithm) the values on the webstats are all over the place. Sometimes there shown much higher values like I get 370sol but web stats say 443 sols and then again 375sol on cmd and web stats say 320sol. Same goes for cryptonight. Something seems bogus.

nicehashdev commented 7 years ago

I am not saying that you should not use algorithm switching, I am just stating that average web stats for certain algorithm may not be accurate due to intermitent periods of your miner not working on that algorithm, but other algorithms.

ChriscomIT commented 7 years ago

Ok, I understand what you saying but honestly the most time my GPUs mine equihash. There are days where it switches 3 or 4 times over the day but sometimes it never switches for more than over one day. Also, cryptonight for CPU on 2 machines gets never switched and the values on web stats are bogus as well, however.

aidonaks commented 7 years ago

@ChriscomIT has a fair point. Even after hours of the same algorithm, the web stats are off. Also, part of the web stats show a 5 min average, other parts use a one hour average. Another issue - the total "accepted rate" shown above for an algorithm doesn't match the sum of the "accepted rates" for each worker shown lower down. What's with that?

That's confusing.

pzacheo commented 7 years ago

I'm mining with RX470 and RX580. I've noticed more stability when mining DaggerDecred, and also is around 20% more profitable than DaggerHashimoto, and more stable chart. Although the chart jump in the long term and in the average is consistent with the payout.

I'm not yet trying v2.0 since it crashed on me so I gave up, have 5 mining rigs and don't want to update them all yet. BTW I've manually selected DaggerDecred only, I'm not using switching.

Some thing I've tried is having some miners in Europe, others in USA and others in Hong Kong, Brazil tends to bring more stable chart or more profits, but I could be wrong. Please devs correct me if I'm wrong.