Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 332. (Read 794124 times)

I was able to reproduce the bug locally, so I made some tests. Here are the results;

NiceHash works as expected - correctly. It sends auth error if p= is above and closes the connection. On the other side, sgminer falls into "bug-loop", where it after every x seconds try to connect and getting back same auth error, thus not working at all. It does stay connected to second pool, but performs no work from second pool. This to me, clearly looks like a sgminer bug, and not bug by NiceHash.

Again, restart of sgminer, fixes this issue.

Now, I am trying to get some ideas how to get past this. Suggestion was to use client.reconnect feature. But here are the catches; if I send client.reconnect to stratum.nicehash.com and port 3333, then miner will perform DDOS attack on NiceHash until it crashes (tested). If I send client.reconnect to some unresolvable host like 0.0.0.0, then miner NEVER tries to connect to real NiceHash anymore.

I will test some more options later, maybe I can, with correct sequence of returned responses, not trigger this bug from happening.

If you absolutely must use p= feature, I suggest you to also use some monitoring utility that restarts your miner in case of idling.

I totally agree with you! Though I did not encounter any problems with the p= option (worked fine for me with SGminer 4.1.0 BAMT) I guess the devs could invest time in adding new features or enhancing already working parts of the service. Really loving this service and I hope it will get even more successful.

I know it's heresy to say that here among folks chasing the highest-priced order, but I think nicehash needs to get rid of the "p=" thing. It might have had its use when there was one or two orders in the system, but now there is steady supply. Instead of wasting time on fixing it or patching miners or whatever, why not spend that energy on let's say porting extranonce support to cgminer 3.7.2 clones for Gridseed. That would bring a lot of hashing power. Or adding something like X11.

I had the same problem today. The price limit feature is buggy and burned me several times.  It only works consistently when you restart the miner.

Whatever benefit I got mining here I gave up by losing hours of hashing.

Sending different subscription ID for every stratum connection. Maybe that will make the difference? Let me know.

When I came home this morning I found my card on the nicehash pool, but it was not getting any work because there was no work above or at the level of p I set.

It should go to my backup pool then right?

Ow and my first order was completed when I got home   that particular one was not profitable though (taking in account the fee)  

I have 2 rigs working with 1 BTC address at NiceHash. Everything was working fine before but now only one of them works at NiceHash, another one doesn't want to join NiceHash anymore and works at reserve pool (but nothing was changed in settings from my side). Does anyone have the same issue?

EDIT: Just joined after 15 minutes of work at reserve pool.

nicehashdev, I've sent you a pm regarding this stalled miner problem.

These debug logs could be helpful yes.

i think, if someone has a issue with nicehash, start sgminer/cgminer with debug mode, save logs to file, and send it to nicehashdev.

I'm sure, it'll help they to find the bug.

Elbandi

I wish I could spend the time to help you find it -- because it just happened twice on one miner and once on another while I had them up on my screen, within twenty minutes of your last post.  I was unable to capture any usable logs, but it went something like this.  I was mining at nicehash with p=7.9 and there were one or two 7.9 orders available (and none higher) that were active and mining properly.  Then they expired or were canceled (they fell off the order list anyway), leaving only lower priced orders, and my miners did not disconnect from the stratum server, instead the GPUs spun down (as seen by decreasing GPU temperatures), and neither accepted nor rejected shares increased.  At this point, my monitoring process will notice stuck accepted shares and restart the miner, but I disabled it temporarily to see if I could gather any more data while it was stuck doing nothing.  Unfortunately before I could, a new 8.1 order popped up and hashing started again.  So I've reenabled my monitor process and will just hope that you find the cause soon.

There are indeed times that nicehash will properly fail over to my backup pool as expected without my monitor process having to intervene, so this problem is almost certainly intermittent in nature.  What you have coded does work at least some of the time, so the source of this problem will probably not be obvious.

Also worth noting is that from what I have observed before, the appearance of a higher priced order will not necessarily pull my miner out of its nap, as that order might already be full.  Perhaps you can think of another non-standard way to get a miner to disconnect before sending authorization error and closing the socket?  I am running sgminer 4.1.271.

I am trully unable to reproduce any kind of misbehaviours regarding p=, no matter what I set and at what kind of timing I start the miner. Everything is working just fine. I tested with sgminer 4.0.0.

So, until I have a way to reproduce this bug I really have no idea what else to do or look. Believe me, I have been sitting in front of code for hours trying to figure out what could have gone wrong, and I couldn't find it. I can paste you the part regarding it and you will see on your own.

Nice to see nscrypt buyers picking up a bit.  Interesting opportunities there.

I think people should give the dev a bit of a brake.  

This website is the first of a kind and has been up and running for 2-3 weeks.  Knowledge is fast moving in crypto coding, and what works on 1 website might no work on another without total starting again on the code.  

Never done much programming myself,  but I've also said to myself and others that if someone tells you it can't be programmed, that means they don't now how to program it.  But that still doesn't mean it's always practically possible mainly due to computer power and speed, which is critical in mining.

Keep up the good work

Of course we respect yor help, shareing ideas, etc.! It's also natural that we can't agree on each and every topic discussed here, therefore it's better to discusss some specific issues via PM. Thanks you all guys for your feedback, we'll try to do our best to provide the best possible service to sellers & providers. And also keep in mind that our service is still young and we're probably not getting enough sleep for the last couple of days

You can only help someone so much.

Lol. I haven't been mentioning the pool by name in this thread because I am avoiding advertising for another pool in this thread... I thought I was showing some forum etiquite. (Nor have you messaged me and asked for more info)

I have observed this behavior on startup, btw.  When there wasn't an unlimited order above the p= setting, and higher orders were full, I was able to restart multiple times and observe the issue. I can try to sniff the traffic from a rig if you need. I have a solution that has been working fine for my rigs, so honestly this isn't even personally relevant.  I have made some solid profits on over 2BTC of hashing power I have purchased from here as well.  I have been more hopeful that my suggestion might bring increased power to nicehash.

Anyway, I have been trying to be helpful. I will happily leave this thread and pool if you don't want me to share my knowledge.

if you want to believe him or not is up to you,  but i can tell you he aint lying, i don't have the smarts to explain in detail but i came from that pool.

Show me sniffed log. NiceHash will drop connection when p is too high for current order, regardless of what kind of orders are there (maxed out or not). We have seen this faulty behaviour only happening after cgminer/sgminer is running for a while, and it always *fixes* it-self when you restart the miner. Completely logical conclusion is that there is bug in cgminer/sgminer, because NiceHash keeps no track of miners, all it gets is socket with IP and port - it doesn't know whether it is a reconnect after a while or a connect from restarted miner. If the bug was on NiceHash side, then restart of cgminer/sgminer would not help you.

Your secretive behaviour does not help you with your credibility. I am not fully sure whether we should even accept your feedback input at all. You talk about some mysterious pool for several pages now already, and we still haven't learned which pool this is.

Buyer or a provider?

As a buyer, you are in complete control of what is being mined.

As a provider, you get work and are paid in BTC. It is completely out of your hands what you are mining (you might even be creating private chains, attacking a blockchain, etc).