As trend2009 states, in real/live trading your limit order is sent to the exchange and joins a queue at each price. If you're placing limit orders right at/near the bid/offer at the top of the book, then you're placing limit orders right where all the action is. i.e. you're in HFT no-man's land ... And so your speed, proximity to the exchange compared with others, and how long ago you actually placed the orders, will be the factors that determine where in the queue you sit. Other factors will be things like how other traders are changing or canceling orders around you, plus whether or not there is anything fundamental happening at the time ... NT has an algorithm so that sim trading is a bit more realistic than simply assuming you're always at the front of the queue ... but it is never going to be able to duplicate exactly, and always, and for all instruments, the non-linear, reflexive processes that combine to determine whether and when your order gets filled. You need to determine the real "slippage" (which in this case means the extent to which your live limit orders fare worse than your sim ones). 1. Run the strategy both live and in sim at the same time, on two separate NT charts. 2. At the end of the session, compare aggregate live results with aggregate sim results. How many trades are missed in live versus sim? % percentage winners? etc... 3. Compare individual executions on the live chart with the sim chart. 4. Do this for a number of days, and determine some sort of adjustment (or efficiency) factor by which your sim results need to be adjusted to better approximate live. 5. If you're based in Fiji and trying to trade CME from a laptop with a mobile connection from the beach, consider co-location somewhere closer to the exchange, etc, and repeat the above measurements. Does that makes a difference? Etc ... 6. Etc ...
Great advice. I will compare Sim with actual side by side. I think it does all have to do with actual market impact and non-linear dynamics that simulation just can't account for.
Another element to take into account is whether you have selected to disable the entry/exit algorithm by selecting the "Enforce immediate fills" option. Clicking that button disables the algorithm that mirrors exchange action, and leaves you with something more rudimentary. I had one strategy that behaved like a polar opposite when that option was enabled or disabled.
I did not have that selected but thank you for the information. Any info to debug is very helpful. Thanks.
First, you have to know that if you are using Sim101 or MarketReplay, the fills are just fantasy. So forget about using them, they are just a waste of time. If you want to do forward testing in paper mode, use an IB simulated account, this is as good as it gets. From a backtesting point of view, add a 2nd timeframe set to 1-second, and use it for your orders ... your backtests will become much more realistic (even if your main timeframe is a low-level tick/volume chart). Last, but not least, if your strategy uses CalculateOnBarClose=false, it cannot backtest properly, no matter what you try. Feel free to ask more specific questions.
Good comments. I agree, I am using Sim101 and the fills are fantasy. I was thinking IB simulated account as well. Do you know how much deposit to get or is that free for testing? I will try 1-second. Appreciate the comments.
In my experience, the IB simulated account ensures price has to trade through a LMT before being filled, it also ensures the fill price is equal to the LMT price, it never gives a fill on a STP order better than the STP value (even though, this can happen in real life, but so rarely it is just better to provide a fill with zero or negative slippage), the latency to the IB simulation server models whatever latency I get to the exchange (through the IB servers anyway) much better than Ninja alone can do, I have the IB native OCO supported directly by the IB simulation server, and Ninja operates exactly as it does with my real IB accounts. Ninja Sim101/MarketReplay fill engine has major flaws, I have seen it give positive slippage intraday on LMT orders (up to 10-ticks - ha!), its fills on STP orders have plenty of positive slippage too, and contrary to backtesting there is no way "fix" these issues (for backtesting purpose I wrote my own "BetterThanDefault" fill-type).