Backtesting Pains-How to store data locally for multiple backtestings at wire speed

[thstart]

...But, we're clearly miscommunicating because there's no "high frequency stuff" involved in anything in my discussion....

I included latency in high frequency to make conversation short. Meaning I was focusing on the high speed of the events. No matter if you place orders or not. For example pinging is one form of active monitoring without actually trading.

...
So to use the correct terminology, all my discussion was related to intraday and EOD trading.

This makes more sense of course.

...
...turn around time from making a trade decision on data, submitting a market order (or at the money limit order), and getting conformation.

The faster turnaround can be, the lower the slippage.

I agree it is important. While for 3-5 days trading prospective it does not matter much. Of course I would watch intraday where to enter but my strategy do not depends much from these intraday fluctuations.

 

[tickzoom]

Quote from thstart:

I included latency in high frequency to make conversation short. Meaning I was focusing on the high speed of the events. No matter if you place orders or not. For example pinging is one form of active monitoring without actually trading.

This makes more sense of course.

I agree it is important. While for 3-5 days trading prospective it does not matter much. Of course I would watch intraday where to enter but my strategy do not depends much from these intraday fluctuations.

We agree. So it was only miscommunication.

Wayne

 

[PowerST]

Quote from tickzoom:

Excellent question. There are EOD traders using TickZOOM and I begged the question of why use a real time system for EOD trading.

They gave me several answers:

1. Many exchanges now have over night sessions. This means that by the time they get the EOD data updates in the evening, the market has already moved on the over night session. Monitoring a real time feed allows EOD traders to get the settlement price "in real time" rather than wait for the EOD data provider hours later.

2. Some EOD traders want to trade shorter term or more sophisticated orders which can't be expressed by an ordinary stop or limit order. So they use an "emergency stop" and let an order server handle the trades.

3. Others want to respond withing milliseconds to certain events rather than wait all the wait till end of day. That's just another way of restating #2.

There are more reasons but these are the most common reason for monitoring a real time data feed.

Sincerely,
Wayne

This is very interesting.

Let me point out that there was an article in Future Magazine around 2 years ago written by a product manager at one of the big algorithmic trading software companies, if I recall FlexTrade:

http://www.flextrade.com/

That article was also about EOD trading, and took the topic into detail about using algorithmic trade execution strategies to place orders. In particular, the article was targeted to CTAs and one of the concerns was trading large quantities and moving the market. So the most simple algorithm would be to break large orders into multiple smaller orders. But it was more than that. The article talked about standard (and it seemed well known) strategies for this kind of thing. I don't recall the exact strategies, but I recall complex real time trade execution strategies looking at bid and ask, whatever.

In my opinion this is a separate topic from backtesting. Makes sense to backtest using the best in class backtesting software for your needs (a topic close to my heart as the developer of an EOD backtesting software), then use the best in class trade execution product to execute trades (or in a post talking about FlexTrade I should say the best that you can afford, I understand that FlexTrade is expensive).

I am a unclear why the original poster wants to backtest in real time. I think of backtesting as something you do over long data spans, and from that you decide on a strategy to trade. Whether you are backtesting EOD over 20 years or tick data over 3 months, it would seem that adding the current day to the backtest real time is not of much consequence. Therefore, I wonder if it can be terminology, where the original poster actually meant strategy execution software rather than backtesting software.

 

[sanjay_arora]

Quote from PowerST:I am a unclear why the original poster wants to backtest in real time. I think of backtesting as something you do over long data spans, and from that you decide on a strategy to trade. Whether you are backtesting EOD over 20 years or tick data over 3 months, it would seem that adding the current day to the backtest real time is not of much consequence. Therefore, I wonder if it can be terminology, where the original poster actually meant strategy execution software rather than backtesting software.

Actually the original post was about creating a feed server that would take historical feed by CD and add to it with the real time quotes. That was to be a server on the LAN to provide data at LAN speeds to a proposed GRID of common computers to run multiple simulations/backtests/optimizations.

One part of hypothesis was that continuously running strategies (in simulation mode) would generate alerts on strategies for which conditions have reversed...e.g. market has become trendless for a trending strategy, or a arb strategy that had become unprofitable N years ago (maybe due to its being exhausted in its time & now forgotten) has suddenly started generated profitable patterns, or N number of other permutations.

As far as I am concerned, a person running a simulation in my office should not be concerned about data, historical or real time, both should be available to him seamlessly at LAN speeds. Paper trading becomes part of backtesting...one need not bother/even know about changing data sources.

 

[promagma]

Quote from tickzoom:

Good point. Nobody who's anybody sends orders to the brokers or exchanges when doing anything intraday. TickZOOM, for example, uses signal order processing which inherently means that the broker never sees real stop or limit orders. Instead, they only see an "emergency stop" and market orders or at the money limit orders.

Sometimes you might want to hide your intentions .... if you want thousands of shares, you might wait and pounce with a market order. But I think sometimes there is more advantage to parking a limit order. You are adding liquidity so you get the ECN rebate, and you are more likely to get your fill if the market just touches your price and reverses.

Especially orders in the first minutes of trading .... the 9:30 or 9:31 minute bars may indicate you would get filled to buy at 11.10, but in reality it was only 200 shares at that price, and if you send an order after the fact you can't even buy at 11.12.

 

[promagma]

Quote from thstart:

.5-1 sec is a lot of delay, I know why - this is not a problem in your system. It simply a combination of regulations (who has the right for <1 sec rule), and law of physics.

This 1-second rule for special people ..... what is it?

 

[thstart]

Quote from promagma:

This 1-second rule for special people ..... what is it?

Broker/dealers, etc. can ping the market for orders. If up to 1 sec they don't find an order, they can cancel the request.

Say, they test the market at 20.7, if there are not orders at this level, they cancel the order. If they do that up to 1 sec, nobody is seeing that.

 

[sanjay_arora]

Quote from thstart:

Broker/dealers, etc. can ping the market for orders. If up to 1 sec they don't find an order, they can cancel the request.

Say, they test the market at 20.7, if there are not orders at this level, they cancel the order. If they do that up to 1 sec, nobody is seeing that.

That's apartheid to the trader

 

[thstart]

Quote from sanjay_arora:

That's apartheid to the trader

Yes, and all these millisecond races doesn't make much sense if you are not one of them, close to the exchange, etc.

Which is OK because to make a difference in a millisecond race you need a lot of leverage.

Here in California, the distance to the exchanges is so long that the signal traveling back and forth has significant lag by the physical laws.

From other side PIMCO here is huge, but they are not in the millisecond race.

 

[tickzoom]

Quote from promagma:

Sometimes you might want to hide your intentions .... if you want thousands of shares, you might wait and pounce with a market order. But I think sometimes there is more advantage to parking a limit order. You are adding liquidity so you get the ECN rebate, and you are more likely to get your fill if the market just touches your price and reverses.

Especially orders in the first minutes of trading .... the 9:30 or 9:31 minute bars may indicate you would get filled to buy at 11.10, but in reality it was only 200 shares at that price, and if you send an order after the fact you can't even buy at 11.12.

Interesting.

One down side to using limit orders which causes what you describe above is that in a very liquid market your order can be behind others in the order queue and possible not get filled.

In low liquidity markets, limit orders are better to prevent a big slippage for market orders.

TickZoom users "soft" limit orders I'll call them which are based on signal order processing.

In your strategy you code limits, stops, etc. but rather than send those to the broker, it automatically watches the bid/ask prices and fires a market order when appropriate to execute the "soft" limit or stop.

Of course, I repeat we have "hard" stop meaning sent to the broker as an "emergency stop" just in case of loss of connection.

Our experience and research finds this to be highly effective for several reasons. This allows internal logic to have more elaborate types of exits for money management and more.

Plus it allows multiple different strategies running on the same symbol which gets extremely crazy to do with sending all those orders to a broker.

One feature we discuss adding is using "at the money" limit orders as an option for less liquid markets.

But as you say, you run the risk of the order queue and not getting filled. But we'll allow parameters to allow a "better than the money" window.

Those things will need some experimentation to figure out what works. But I avoid illiquid markets personally anyway.