Forums  > Trading  > Latency for backtesting  
     
Page 1 of 1
Display using:  

LM


Total Posts: 9
Joined: May 2007
 
Posted: 2012-06-04 11:31
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


Total Posts: 56
Joined: Jan 2009
 
Posted: 2012-06-05 00:30
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.

leftic


Total Posts: 79
Joined: Jun 2007
 
Posted: 2012-06-05 12:45
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?

LM


Total Posts: 9
Joined: May 2007
 
Posted: 2012-06-05 13:36
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
Founding Member

Total Posts: 8243
Joined: Mar 2004
 
Posted: 2012-06-05 14:24
It tells you how busy (or more accurately: how slow) the matching engine is (for the respective trade).

The Chaos Army seems suspiciously well-organized.

LM


Total Posts: 9
Joined: May 2007
 
Posted: 2012-06-05 14:42
FDAXHunter,
thank you.

derek


Total Posts: 56
Joined: Jan 2009
 
Posted: 2012-06-05 22:16
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


Total Posts: 374
Joined: Jun 2005
 
Posted: 2012-06-14 00:14

> 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.


LM


Total Posts: 9
Joined: May 2007
 
Posted: 2012-06-14 10:21
We are in the research stage, currently we use a bought tick data.
Previous Thread :: Next Thread 
Page 1 of 1