Hi,
Some users were complaining about improper orders sorting, so here I'll explain in details the logic of orders sorting. Sorry for the late replay, but we had to double check the algorithm on our test systems. There is nothing wrong with orders sorting, it just needs a bit of additional explanation. The logic of orders sorting is not trivial. We'll also add a separate FAQ for this topic.
1st Rule: First-Come-First-Served with price evaluation.
2nd Rule: Miners switch to better paying orders gradually not instantly (to prevent too frequent disconnect and work restarts on miners).
Example 1:Let's presume currently there are a couple of running orders:
Order #12 @ price 0.9 … 1 Gh/s limit … running (100 miners)
Order #11 @ price 0.8 … no limit … running (all remaining miners)
Order #15 @ price 0.7 … no limit … in queue
Order #10 @ price 0.5 … no limit … in queue
Event: Order #11 was finished, new list:
Order #12 @ price 0.9 … 1 Gh/s limit … running (100 miners)
Order #15 @ price 0.7 … no limit … running (all remaining miners)
Order #10 @ price 0.5 … no limit … in queue
Event: Order #10 is edited at price 0.7, new list:
Order #12 @ price 0.9 … 1 Gh/s limit … running (100 miners)
Order #15 @ price 0.7 … no limit … running (all remaining miners)
Order #10 @ price 0.7 … no limit … in queue
Order #10 stays in queue even if it was submitted
before Order #15, because Order #15
was first to set higher price. This is to prevent placeholders – one would submit placeholder orders with very small prices and then would just increase price when the opportunity would be good and thus overtake all other bidders with initial
same pricing. We don't support this, because it is not fair. The first that sets a particular price will be first served at that particular price. No overtaking at same price level (the same logic is used by cryptocurrency exchanges).
Example 2:Let's presume currently there are a couple of running orders:
Order #12 @ price 0.9 … 1 Gh/s limit … running (100 miners)
Order #11 @ price 0.8 … no limit … running (all remaining miners)
Order #10 @ price 0.7 … no limit … in queue
Event: A new order Order #13 is added at price 0.9 (the same logic would be if this would be edit of an existing order by increasing price at existing order), new list:
Order #12 @ price 0.9 … 1 Gh/s limit … running (100 miners)
Order #13 @ price 0.9 … no limit … waiting (waiting for miners)
Order #11 @ price 0.8 … no limit … running (all remaining miners)
Order #10 @ price 0.7 … no limit … in queue
Note that even if Order #13 is set at higher price it's still waiting for miners. It will take several minutes before miners will start to get assigned to new order (to prevent too frequent disconnect and work restarts on miners). New list after some time:
Order #12 @ price 0.9 … 1 Gh/s limit … running (100 miners)
Order #13 @ price 0.9 … no limit … running (some miners)
Order #11 @ price 0.8 … no limit … running (all remaining miners)
Order #10 @ price 0.7 … no limit … in queue
After some more time:
Order #12 @ price 0.9 … 1 Gh/s limit … running (100 miners)
Order #13 @ price 0.9 … no limit … running (all remaining miners)
Order #10 @ price 0.7 … no limit … in queue
Notice that order Order #11 is finished and out of the list. Even if it was lower paying than Order #13 it was finished before because obviously the order budget was spent meanwhile miners were switching to other order(s).
Keep in mind that order/miner switching is even more diverse when there are lots of orders and lots of price changing. In such times one must be patient and carefully monitor the situation. Also, keep in mind that NiceHash doesn't provide it's own hashing power but redirects hashing power from external providers. This way we are able to provide buyers with hashing power on demand, but on a bidding basis and gradual miners switching. Gradual miners switching protects miners and ensures higher efficiency - even at the cost of slightly, but truly slightly lower paying average - efficiency is more valuable and eventually brings better profits for providers. This concept gives attractive pricing for buyers and good payments for providers, but of course can't provide real-time (true on-demand, at click time) hashing power. Usually the ones that are able to predict these "hot" times and are able to bid prices high enough in advance are best served. We also welcome you to utilize our API
https://nicehash.com/index.jsp?p=api which will allow you to automate orders handling and make buying hashing power at NiceHash even more effective.
BTW: we did rigorous testing to provide proper order sorting but if you still encounter some cases that doesn't comply with the rules, described above, please let us know via email to
info@nicehash.comExample: last night I put in an order for 1.0. With a maximum of 2gh. I never got the 2gh filled yet below me there were orders of 0.8 completely filling up to 3gh and their order was placed AFTER mine.
TheFridge Are you sure this was a
new order for price 1.0? If you were editing existing order, that this would explain the described behavior. If not please send us your order# as well as other order#s (if you have them) to
info@nicehash.com. Thanks!
Thanks for using NiceHash and we all wish you nice hashing!
