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

There are probably like 100 possible reasons why there is negative delta; I will just mention few:
- Remote pool does not respond to shares being sent (timed-out speed).
- Stale shares (remote pool rejects shares as being too late).
- Extra rewards being paid on NH for fast job switching (putting high load on miners with fast job switching causes them to not get full mining speed).
- Remote pool bans your worker thus rejecting all your shares (this one is very evil one - instead of disconnecting you, remote pool simply rejects all your valid shares - internally, it can use these shares to solve blocks, but does not reward you - we believe all MPOS pools do that and there are several large pools that are doing this nasty trick).
- Incorrect remote pool software implementation regarding diff adjustments (some pools do not honour the official stratum specifications that state => diff change affects all next jobs); some pools don't even send starting diff before first job (I think even ckpool does that sometimes). These shares are then rejected by the remote pool as shares above target.
- And don't forget about variance. If your pool is working with very high difficulty, miners do not. You will see more steady speed on NH, but fluctuating one on remote pool (because there are not much high shares found, but they count more). As a consequence, delta will fluctuate too. If you set extreme pool diff, you may not find a share for several minutes. In that case, remote pool speed is of course 0. But that does not mean you are not mining. All speeds are calculated out of received shares (and out of received responses from remote pool) and are therefore highly dependent on pool difficulty.

What causes the Delta % of an order to go into the red. I understand Delta is the difference in measured hashrate between the pool and nicehash, I'm just not sure what causes it? I had a fixed order that was at -100% Delta for a few mins so I was paying for hashrate that wasn't being counted by the pool, it seems strange the nicehash servers can tell the pool isn't getting the hashrate yet it continues to charge for that hashrate.  I deleted the worker at the pool and created a new one with the same name which seemed to work, I just want to know what causes a negative delta % and is there anything that can be done on my end to prevent it, also why does the nicehash system allow a -100% delta rental to keep paying for hashrate they aren't showing at the pool?
Thanks
Best Regards

Odd, I always use the pre-set pools from my list which has been '1,d=xxx'.
Not sure why it changed to ';', my bad on that then.

I'll try again with the ',' and we'll see.

Weird..

The bridge status to me is gibberish so it makes no sense to me.

If your order is 100% dead, of course, it will be cancelled.



Same goes for your order #484121.

Also, after checking your pool password, we immediately saw error: you wrote 1;d=20000 instead of 1,d=20000. Probably pool refused authorization and thus order was dead always. Maybe you should start reading bridge status? Because bridge status clearly reports back what is wrong.... but yet again, you failed to listen us when we told you to check bridge status.

Ok, so I tried 2 fixed orders again with the difficulty set manually to 20,000 which is more than enough, considering even with no difficulty set the pool works 100% from EVERYWHERE else.

My 2 fixed orders were canceled again!

#485018 Fixed
Cancelled - placeholder order 
 0.4582 0.19824378 0.19824378 0.00% 5.00 
 
#484121 Fixed
Cancelled - placeholder order 
 0.4775 0.09690300 0.09690300 0.00% 1.50 


Either your software is bad since the upgrade or whatever you guys did recently, or you are actively canceling and NOT Honoring your own fixed priced orders as price moves up, which is BAD Business in my book.

I think I'm done trying to have you guys figure it out as you seem biased and blame everything else as I've been told by members of the forum in PM's.

No more renting from you guys. Hope everyone else sees this also as a warning not to waste higher $$ on fixed orders.

Because standard orders have higher tolerance for amount of dead time in % as already explained:

Yeah that makes sense. I just don't understand why the fixed priced ones got canceled, yet at the same time I had rentals with non-fixed prices when the prices moved above the fixed price ones and those were kept fine. Same pool same settings.
Just looks pretty suspicious...

Order is dead when there are no valid stratum connections established with remote pool; reasons for that can be many such as bad link between us and pool, wrong authorization, invalid extranonce sizes... but the most common scenario is when pool switches to low diff, which we do not permit - in such case, we terminate connection thus there is no valid stratum connection established and order is marked as dead. Until reconnect kicks in and if pool provides good diff this time, it stays alive (but only if diff is above 16384).

How can it be 'dead' if the pool is alive, settings are correct and it's a FIXED order?

I don't understand what decides if an order is dead or not if all that is correct.

All of your reported orders were >10% dead. By the rules, fixed orders gets cancelled if they are more than 10% dead. For standard orders, this ratio is 50%. That is why standard orders work fine for you, because you have constant changing state of alive/dead, which falls inside margins for keeping order if being standard. It is all explained in FAQ.

If you order is like that:



you cannot expect us just to let it be and consume available fixed hashing power.

Why is it so hard to understand that I didn't have to use that before, still don't have to use it with other rentals and my own miners (KNC titans), and even now I tried it at the standard pricing and worked FINE.

So I'm back to my opinion that some others have PM-ed me about, that is it possible, you guys are deleting fixed price orders if the price goes up, making higher priced fixed orders USELESS??

You clearly do not understand how our system works. If diff is too low, we will drop connection to protect our miners - so they can hash with full speed. Other services don't do this, thus buyers are exploiting miners by either setting too low or too high diffs.

Why is it so hard to append diff parameter to password?

You guys just canceled ANOTHER fixed scrypt order. Same as before. Yet the standard non-fixed orders I have and had before with the same settings did not get canceled. WTH is going on over there???

#482158 Fixed
Cancelled - placeholder order 
 0.3997 0.19390300 0.19034323 1.84% 2.00 

I have not had issues with rentals to this pool with the SAME settings from westhash, nicehash, betarigs, Miningrigrentals ans my own KNC titans. SO it's not a difficulty issue.
.

.

.

Most commonly, the issue is due to too low diffs, especially on scrypt. We do not permit running diff less than 16384. Fastest ASIC miners need even higher than this usually.

Did you set difficulty? According to this: https://www.litecoinpool.org/help#faq you can do it by appending to password: ,d=65536

Try this and you will see what happens then. If this doesn't solve the issue, then closely monitor bridges and you will see why order gets dead - reason is printed out.

OK, here they are :

1:
#478273   Fixed   
Cancelled - placeholder order
0.4125   0.19390300   0.19335290   0.28%   1.00   

2:
#477160   Fixed   
Cancelled - placeholder order
0.3996   0.38790300   0.37451169   3.45%   1.00

--------------------------

Oddly as the price shot up my orders were 'canceled' by your system.
The pool info is and was always fine as I had other miners going to it and I have used it with west/nicehash before
and after since.

SO I'd love to know why the fixed price, which was higher to begin with, was canceled.

We are still waiting for your order id...

I will, because you guys just canceled ANOTHER FIXED one. 

Seems like whenever my fixed price order is below your average price, you cancel it now.
That's pretty fugged up though, as I pay higher than going rate to begin with and you cancel it when the price shoots up for some bullish reason.

Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).

The pool I set is alive and was fine, because I was also renting other rigs to it, including on nicehash which was fine.
So why was it canceled???

As long as you have alive and not dead pool, yes, then we guarantee hashing power for that price. There is also no point in having dead pool, because dead pool doesn't do any hashing.