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

Ouch, miners are all back
Thanks for the quick action

hey down here 2

sometimes i got hashrate from nicehash ..like 5 mins of an hour...

pls nicehash

Unfortunately another DDOS attack, but has been filtered out now.

X11 and X13 no luck but Nist5 is ok now -.-

I'm stuck mining a pool that I need to switch now, losing money!

Down, too often

miner can connect but website offline  

mining works fine

Nicehash seem down O.O, unable to access the site nor point the miner to the server.

Using around 6 miners, some have multiple nvidia 750ti cards, some only one. All hasing to same adress, just added different names for easier maintenance (which was awesome feature btw that you've added)
Using ccminer 1.2, my configs:

ccminer -r 6 -a x11 -s 2 -R 10 -T 60 -o stratum+tcp://stratum.nicehash.com:3336   -O %worker1%:d=0.02
ccminer -r 6 -a x13 -s 2 -R 10 -T 60 -o stratum+tcp://stratum.nicehash.com:3337   -O %worker1%:d=0.02
ccminer -r 6 -a x15 -s 2 -R 10 -T 60 -o stratum+tcp://stratum.nicehash.com:3339   -O %worker1%:d=0.04
ccminer -r 6 -a nist5 -s 2 -R 10 -T 60 -o stratum+tcp://stratum.nicehash.com:3340   -O %worker1%:x

 -r, --retries=N       number of times to retry if a network call fails (default: retry indefinitely)
 -R, --retry-pause=N   time to pause between retries, in seconds (default: 30)
 -T, --timeout=N       network timeout, in seconds (default: 270)
 -s, --scantime=N      upper bound on time spent scanning current work when long polling is unavailable, in seconds (default: 5)

Switching to most profitable algo is done with NHC control. Usually stratum_recv_line failed happens when switching algo, but not always, there's also no fixed time pattern, but usually between 5 -10 min the connection gets reset.

UPDATE: Solved problem by removing "-s 2 -R 10 -T 60" from config.

Keep pumping out those nightly builds of sgminer, don't leave us dev testers high and dry every few other nights.

nightly = nightly

...

- Do you get these lines when miner switches algorithm?
- What mining software you use?
- How many miners you have?
- Do you get blocked/banned?

Used to have many reject when my cards when OC, now i've turned it down to see if it's better.
Now I have 1-2% of rejects and still receive those two lines on all algos, does difficulty influence this? Or how can I improve that?
using ccminer and nvidia 750ti

Bit surprised by the 'profitability spurts' experienced with my few little rig's on nicehash during this past 24h period.  Not that I'm complaining

This service abstracts the pool it's mining on away from the end user and out of the user's control, correct?

So in summary, let me see if I understand correctly:

ipominer used code that works with existing mining software and called it good. Since it worked with 100% of clients 100% of the time, there was no reason to do further testing, right? From my understanding, there's really only a small handful of different mining software out there. Sure there are many versions of sgminer, but the original neworking code is probably all the same from the first version (no, I didn't check this myself - that's just a guess). It just so happened that (nearly?) all software out there sends the initial subscribe and authorize requests in the same way - probably ending up in two separate packets.

nicehashdev used an implementation that was slightly different than most (all?) pre-existing miner applications. Instead of those initial subscribe/authorize requests being sent over the wire in two packets, they were sent in a single packet (as is the case in that C# example). I know nicehashdev said they use separate sends, but it seems whatever they're doing ends up combining messages as in the example. In any case it doesn't really matter, and I'll focus on the example given.

nicehashdev is correct that networking communications data must be treated as a stream and not as individual packets. Data could be split/combined in ways you can't control over the internet - there's no guarantee that data will arrive in the same 'chunks' they were sent. There IS a guarantee, however, that the bytes arrive in the same order as they were sent (this was mentioned earlier).

I tried out nicehashdev's C# example (both subscribe & authorize sent in a single packet) and sure enough the response received was the low diff, then the high diff (received all in a single packet  ). However, splitting the initial subscribe/authorize Send() into two different sends (no pause in-between) resulted in a response with the high diff, then the low diff. Exactly the same data was sent, but splitting the data into two send events (and therefore packets) resulted in the 'proper' response.

I've dealt with this kind of problem before in my own experience with network coding. The issue is always in how I read the data - not how it was sent. I always have to remind myself that the receiving end needs to treat the incoming bytes as a stream - never as a 'packet'.

Therefore it is my conclusion that nicehashdev is correct and that ipominer's implementation does not correctly parse the received data. This also explains why other pools don't have this issue with NiceHash.

The situation isn't helped by the fact that the stratum protocol documentation is kinda poorly organized. Seems like programmers are sort of forced to test their code by comparing it to how other preexisting implementations handle things, rather than coding according to the documentation (hard to do since it's seemingly spread out in an unorganized fashion). Frankly I'm surprised these sorts of problems don't pop up more often.

anyone having problem when switching of pools happens too often?
sgminer just stuck at switching and kept doing it.

would increasing switch gap help?

ipominer / flound1129 / atomicchaos, if it's any consolation unfortunately this is typical nicehash MO - whatever happens blame someone else. I've been mining here since day one and I'm a big fan of the concept but I have given up on trying to resolve any issues. Couldn't connect to the stratum for two days - the suggested solution was to change my IP because their DDOS protection was blocking me, then it turns out it should have unblocked me after three hours so it must "something on my end", as if I'm that dumb. Stratum downtimes happen often, not reflected in the stats on their front page though. Great idea, poor execution. A lot more issues than with any other pool or rental service I've dealt with. Have solid backups if you're a rig owner, count your pennies carefully if you're a renter, be prepared for unhappy miners if you're a pool.

The print I showed is dump from Wireshark - what was sent from Ipominer pool. There was no reversing made by proxy, proxy only read that data. Obviously pool "messed" which diff was sent lastly. If you split subscription and authorization into 2 packets (make some delay between sending them), then the order of delegated diffs is high then low. Please, try the short example I provided and you will see it with your own eyes what happens if you don't believe me.