Latency for backtesting

leon_margolin · Post by **leon_margolin** » Mon Jun 04, 2012 11:31 am

We're developing an HFT strategy for highly liquid futures traded at Eurex. We are planning to colocate our server and to use data feed of QuantHouse and execution API of ObjectTrading. Backtesting is performed on tick data bought from QuantHouse, where timestamps have millisecond resolution (BTW, trades and quotes are sorted separately, so if trades and quotes have a same timestamp, they are not sorted). My question is about latency we should use for backtesting. I define latency as:

data feed latency + internal processing time (several microseconds) + execution latency.

We simulate this by adding X ms to the feed time (T) of the tick that triggered the trade, then if the last tick with the feed time not later than T + X was a quote we use its book for execution, otherwise (if the last tick with the feed time not later than T + X was a trade) we wait for an incoming quote and its book is used for execution.

So my questions are:

1. Is our execution model reasonable?

2. What X should be used for our setup?

3. Could you suggest other (not too expensive) setup in order to reduce any kind of latency?

Thanks in advance.

derek · Post by **derek** » Tue Jun 05, 2012 12:30 am

Hi LM,

I am willing to share some information. But I have to admit that since my shop has a native Eurex feed connection, I am not aware of the format in which QuantHouse provides market data.

The native Eurex timestamps would provide microseconds resolution for Orderbook Delta (->"Quote") and Trade Information (->"Tick") messages.

Out of curiosity, could you please provide just one recent example of what QuantHouse would provide in case of a trade?

Please include both a "Quote" and a "Trade" record. Do they provide the Eurex performanceIndicator as well?

ad 1.) Your execution model seems reasonable, given that you already add X ms to your trigger timestamp instead of X µs.

There is actually 3 components.

(X) time from tick until the market data gets to you

(Y) your internal latency

(Z) latency from your application back to exchange

Both X and Z depend on your providers. I assume you have backtested your strategies and you have already identified how long your X+Y+Z can be before your opportunity will vanish.

ad 2.) I am not going to post the numbers here publicly. Update your profile, and I'll PM you some statistics of the (X) and (Z) delays which I am seeing (we are a NCM in colo, i.e. non-QuantHouse/ObjectTrading setup)

ad 3.) "expensive" is really relative to what you are aiming for. I would assume your model is probably good as it is and you in reality do not need to/want to compete with the real low-frequency guys.

alebron · Post by **alebron** » Tue Jun 05, 2012 12:45 pm

Hi derek,

I'm looking at the Eurex enhanced broadcast solution spec, and I see no mention of performanceIndicator. Is your native feed different from this one?

leon_margolin · Post by **leon_margolin** » Tue Jun 05, 2012 1:36 pm

Derek, many thanks.

I believe I'll post examples of QH quotes and trades tomorrow (I am not sure I use all the provided information, so I'll ask the guy who dealt with the data).

BTW, what is Eurex performance indicator?

FDAXHunter · Post by **FDAXHunter** » Tue Jun 05, 2012 2:24 pm

It tells you how busy (or more accurately: how slow) the matching engine is (for the respective trade).

leon_margolin · Post by **leon_margolin** » Tue Jun 05, 2012 2:42 pm

FDAXHunter,

thank you.

derek · Post by **derek** » Tue Jun 05, 2012 10:16 pm

leftic. The performanceIndicator was added end of last year.

It's part of the packet header, not the individual messages.

Eurex will batch multiple orders together for one market data update. The performanceIndicator tells you how long it took from arrival of first order within a batch to sending out of the market data update.

nikol · Post by **nikol** » Thu Jun 14, 2012 12:14 am

> BTW, trades and quotes are sorted separately, so if trades and quotes have a same timestamp, they are not sorted

my gut feeling tells me, it is not nice. storing stream as is received is the best (IMHO) as it gives idea of what you get on YOUR computer and with YOUR connection and, therefore, will give real but not idealistic picture.

leon_margolin · Post by **leon_margolin** » Thu Jun 14, 2012 10:21 am

We are in the research stage, currently we use a bought tick data.