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
Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 168. (Read 794394 times)
July 08, 2015, 09:26:29 AM
July 07, 2015, 09:05:01 PM
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.
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.
July 07, 2015, 10:36:36 AM
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.
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.
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.
July 07, 2015, 09:35:54 AM
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.
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.
July 07, 2015, 12:30:59 AM
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.
I don't understand what decides if an order is dead or not if all that is correct.
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).
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...
Because standard orders have higher tolerance for amount of dead time in % as already explained:
Quote
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.
July 06, 2015, 04:14:15 PM
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.
I don't understand what decides if an order is dead or not if all that is correct.
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).
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...
July 06, 2015, 03:04:43 PM
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.
I don't understand what decides if an order is dead or not if all that is correct.
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).
July 06, 2015, 02:40:10 PM
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.
I don't understand what decides if an order is dead or not if all that is correct.
July 06, 2015, 01:44:23 PM
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?
Why is it so hard to append diff parameter to password?
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??
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.
July 06, 2015, 12:46:05 PM
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?
Why is it so hard to append diff parameter to password?
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??
July 06, 2015, 03:19:46 AM
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.
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.
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.
.
.
.
Why is it so hard to append diff parameter to password?
July 05, 2015, 06:57:11 PM
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.
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.
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.
.
.
.
July 05, 2015, 05:41:54 PM
Quote from: NiceHashSupport [sup
[/sup]link=topic=562238.msg11778302#msg11778302 date=1435903678]
Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).
Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).
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.
We are still waiting for your order id...
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.
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.
July 05, 2015, 02:37:10 PM
Quote from: NiceHashSupport [sup
[/sup]link=topic=562238.msg11778302#msg11778302 date=1435903678]
Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).
Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).
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.
We are still waiting for your order id...
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.
July 05, 2015, 02:14:09 PM
Quote from: NiceHashSupport [sup
[/sup]link=topic=562238.msg11778302#msg11778302 date=1435903678]
Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).
Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).
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.
We are still waiting for your order id...
July 03, 2015, 06:26:15 AM
Quote from: NiceHashSupport [sup
[/sup]link=topic=562238.msg11778302#msg11778302 date=1435903678]
Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).
Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).
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.
July 03, 2015, 01:07:58 AM
Why is a 'Fixed' priced order canceled by your system as a placeholder?
Fixed orders needs to be 90% or more alive, else they get cancelled. If we didn't enforce this rule, someone may easily block fixed orders by creating dead fixed orders and taking all "reserved hashing power" for fixed orders.
So why bother with a fixed order, if the higher than standard price YOU GUYS set at the purchase will not be honored by you??
Wasn't the point of a fixed order the fact that no matter what I'll be guaranteed that price??
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.
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???
Contact [email protected] with order # for further lookup. You can check it out on your own too (past orders, view details).
July 02, 2015, 08:08:47 PM
Why is a 'Fixed' priced order canceled by your system as a placeholder?
Fixed orders needs to be 90% or more alive, else they get cancelled. If we didn't enforce this rule, someone may easily block fixed orders by creating dead fixed orders and taking all "reserved hashing power" for fixed orders.
So why bother with a fixed order, if the higher than standard price YOU GUYS set at the purchase will not be honored by you??
Wasn't the point of a fixed order the fact that no matter what I'll be guaranteed that price??
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.
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???
July 02, 2015, 02:21:51 PM
Why is a 'Fixed' priced order canceled by your system as a placeholder?
Fixed orders needs to be 90% or more alive, else they get cancelled. If we didn't enforce this rule, someone may easily block fixed orders by creating dead fixed orders and taking all "reserved hashing power" for fixed orders.
So why bother with a fixed order, if the higher than standard price YOU GUYS set at the purchase will not be honored by you??
Wasn't the point of a fixed order the fact that no matter what I'll be guaranteed that price??
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.
July 02, 2015, 12:19:38 PM
Why is a 'Fixed' priced order canceled by your system as a placeholder?
Fixed orders needs to be 90% or more alive, else they get cancelled. If we didn't enforce this rule, someone may easily block fixed orders by creating dead fixed orders and taking all "reserved hashing power" for fixed orders.
So why bother with a fixed order, if the higher than standard price YOU GUYS set at the purchase will not be honored by you??
Wasn't the point of a fixed order the fact that no matter what I'll be guaranteed that price??
Jump to: