Quoting engine waits to send new orders

[ctubio]

It happens because it only send new orders if the new order have a different price than the previous order.

For example, this impacts when canceling orders manually, it will not place a new order until a new price is decided to be send. see #70

[Camille92]

Hello Carles and @beegmon,

I just have to say in defense of this update that not sending too many orders to the market is convenient as it limits the risk of sending a "taker" order if in between the time Tribeca sent the order and the market receives it someone put an order at that price or lower.

It also mitigates the time when Tribeca is not on the market (in between orders).

If it's possible imho the best solution would be to "check" if orders are in place every 1mn or so.

Cheers and have a nice day,

Camille

[ctubio]

Hello Camille, tribeca never sends taker (market price) orders; all orders sent are limit orders. Since there is no way to make a taker order, and if tribeca is actively sending orders, there is no reason to stop sending orders just because the price of the new order is equal to the price of the previous order and this previous order was already canceled (tribeca should instead of keep thinking that the order is open, should know that the order is already closed, so new orders can effectively be send, no need to wait)

[Camille92]

I agree on this, Tribeca should know that the order has been canceled.

But also I don't see the need to send orders all the time if the price did not move :p.

And I know that tribeca never sends "voluntary" market orders but it does happen from time to time (especially when your VPS is far from the exchange server).

Here how it happens when server are quite far apart: (let's take 10ms, a fast connection from the USA to HK). 1) The market information goes from the server to Tribeca(10ms) 2) Tribeca emits action from that information (1 ms) 3) The order goes from Tribeca to the exchange orders (10ms) 4) The server includes our order (quasi-nothing ms).

There is more than 20 ms total of latency.

If in this time someone placed an order matching the order Tribeca is sending, you're going to be taker ;p.

Ie: The market is at 100 - 102, and you're on top of the market. Someone goes on top of you on the Bid side at 100.01, Tribeca will want to cancel your order at 100 and send a new one at 100.02. However if during that 20ms someone sends a big sell limit order at 100, when you order arrive at 100.02 you're a taker!

That's why it's good to be close to the market :)

Well anyway, I know you do your best with Tribeca, and a solution to 'check' if the order is still there is a really good idea!

[Camille92]

Ok I went on the last version as well.

Big problem is that because of that, it doesn't get properly on the order book. Sorry for the inconvenience!

[ctubio]

Hello Camille, sorry that i insist but there is no way to be the taker, if the latency makes your order match an existent one, it will not match, it will be rejected; because tribeca sends only taker orders (by setting the order type parameter when placing the order), and taker orders cannot be maker orders in any case, will be or rejected or placed in the order book of the exhcange.

The only way to send maker orders is to explicity not set LIMIT in the Sumbit Order manual form (instead needs to set Market).

[Camille92]

I'm staying in my position. :p Sending a limit order doesn't automatically make you a 'maker'.

You can try to send manually buy orders limit at an higher price than the lowest ask and you'll see that it works. :)

But it's a non important issue in comparison of the one here and we can't do anything about it (apart from moving your VPS closer to the market).

[ctubio]

in Coinbase and OkCoin i tested (long time ago) and found limit order to be respected, so rejected or palced in the book, never matched. did you see this happening in Coinbase/OkCoin? or was in Bitfinex? (Bitfinex also clearly defines the order type, so i didnt tested; maybe i should xD)

[Camille92]

I just tried to buy 0.01 btc at 2000 on OkCoin and it worked just fine ( I bought it at market price 1680.52) :)

[ctubio]

f*ing s*T i bought it at 1680.03 xD

okok will review this too in a new issue'¡! many many thanks for notice this'¡!! i though it was working super fine already :sob:

[beegmon]

@Camille92 I think is correct here, given the example with latency, but only if Tribeca isn't setting the "Post-Only" option for limit orders (I am talking about GDAX/Coinbase specifically, not sure about other exchanges).

Matches can occur, and I have seen them several times when setting limit orders manually from the web ui, that are close the market price, and things or volatile on GDAX. This is due to the fact that despite your limit order being a limit, it will match an order that has frontrun you do to latency or swift market changes. When a match occurs, you end up being the taker.

I understand not everyone one can run a VPS/VM that is co-located with an exchange, or close enough from the network prospective to avoid severe latency differences, but at the same time its best practice and helps avoid the risk latency discrepancies causing issues. You can't expect best performance, and the reduction of risk against taker behavior if you aren't providing triebca with the lowest possible link between it and the exchange, especially if you are playing really really close to the market price with Tribeca.

For GDAX specifically, I think it should be possible to set the post only option for limit orders. That will ensure the order is rejected if it matches, enforcing maker behavior. I am not sure if other exchanges support such an option.

Look here -- https://docs.gdax.com/#place-a-new-order -- under limit order parameters

And Here -- https://support.gdax.com/customer/en/portal/articles/2426596-entering-market-and-limit-orders -- under advanaced limit order options for more information.

This is all thanks to Price Improvement and the Price/Time ordering of most exchanges

[ctubio]

so, @beegmon, in this orders, if you check in your history of gdax reports, you see that you end up paying fees on gdax? that is cruel :sob: will try to investicate at #73 (we already use postOnly, but will make sure it works as expected)

[beegmon]

I don't pay fees 99% of the time with Tribeca, but then again I don't really play to close to the market price to begin with, which helps as there is less churn deeper in the book when the market is pretty quiet.

However, when things get volatile it does pop up occasionally (maybe 1 - 100 order submissions). It was much worse when I wasn't running Tribeca on an instance in AWS US-EAST-1 (which is were the API docs say you should co-locate for minimal latency). If latency is bad for a user like 10ms to-from the exchange, you could easily wipe out profits if doing a lot of trades in a short period of time.

[beegmon]

In regards to sending new orders. Would it be possible to make this option selectable?

For those of us that co-locate Tribeca with the exchange it's trading in, or with minimal network latency, I would think we would want Tribeca as fast/reactive as possible.

Maybe making it so there is an option to make new order submittal fast (if in a low latency environment) or slow (if in a high latency environment) would cover use cases for both users, and not put anyone at risk if they are running non-optimally?

[ctubio]

but but but there is no risk if tribeca correctly sets the order type as LIMIT, so i would like to fix OkCoin at #73 and forget about the risk of placing orders with fees.

About the waiting time, having risk or not, seems useless to wait for something that is not real (tribeca thinks that a order exists but it doest), this generates a percetible waiting time, but who knows what else is also affected, so better to fix and let tribeca know really the real state at all times, i belive

[beegmon]

That make sense as well. Better to let Tribeca operate on old but correct data (if there is significant lag between the exchange and the server/VPS/VM running Tribeca), rather than on old and bad data.

The risk of placing new orders is the same...If you are behind the market by 10ms, because Tribeca isn't co-located with the exchange, then there is nothing you can do beside moving it closer/co-locating it.

GDAX and other exchanges that provide or enforce a post_only type of limit order behavior are just more helpful in this situation as it keeps you from submitting limit orders that might get matched immediately, and therefore making you a taker.

So your choices are use an exchange that doesn't allow for matching/filling of limit orders immediately (post_only behavior/or what I would think the true behavior of a limit order should be).

Or move your Tribeca instance closer so you can keep from getting outrun by others on an exchange that doesn't provide post_only type of limit order behavior. Full well knowing that there is still a risk that limit orders being placed by Tribeca could still end up being a taker on these kinds of exchanges.

[Camille92]

Server location of Gdax is indeed AWS-US-EAST-1, I get a ping of 0.2 from them there :)

[Camille92]

Hey guys, https://github.com/ctubio/tribeca/commit/685f6b066db06ba7b96fc729eaba86bf1401ceb5 seems to block AK-47 to perform correctly. Is it intended?

I removed it from my version and everything works fine for me. I don't really get where is the problem now --' https://github.com/ctubio/tribeca/issues/72

[ctubio]

@Camille92 sorry if it doesnt, it must, so this afternoon i will reinvestigate the multiple orders blocked of AK-47; is just that line that needs a different condition

[Camille92]

Thank you Carles,

I'm investigating as well but basically there is something weird somewhere and I can't really put my finger on it #70 #72

[ctubio]

btw, to speedup latency, there is a new dependency thanks to https://github.com/caseyWebb/tribeca, you must have installed g++, and simply run as usual npm install or npm run latest, cos now the websocket is a compiled binary thanks to https://github.com/uWebSockets/uWebSockets (if no g++, then the binary used will be generic for your OS [see node_modules/uws/build/Releases to check that you had really build your own binary for the current machine])

[ctubio]

no worry to much for AK-47, i will try to fix this afternoon

[beegmon]

Awesome! Good call on uWS! I was just going to open a issue to see if that could be swapped in for ws since it appears to be much more efficient/faster.

[ctubio]

im sorry i just tested without problems AK-47 in Coinbase/OkCoin/BIfinex

in what exchange was it failing for you?

thanks'¡

[Camille92]

Heeyy,

The problem doesn't come before a few minutes (maybe 1h). It is, for me, mostly visible in Coinbase LTC BTC and ETH BTC , but usually arrive on all markets (Ok and Gdax)

I send you screenshots and more details when I'm home !