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