Trading multiple instruments

[mikeyork]

OK. Here are the first three lines from TraceOrders:

9/8/2008 8:59:00 AM Entered internal PlaceOrder() method at 9/8/2008 8:59:00 AM: Action=SellShort OrderType=Market Quantity=3 LimitPrice=0 StopPrice=0 SignalName='IntraDn' FromEntrySignal=''
9/8/2008 8:59:00 AM Entered internal PlaceOrder() method at 9/8/2008 8:59:00 AM: Action=SellShort OrderType=Market Quantity=4 LimitPrice=0 StopPrice=0 SignalName='IntraDn' FromEntrySignal=''
9/8/2008 8:59:17 AM Entered internal PlaceOrder() method at 9/8/2008 8:59:17 AM: Action=SellShort OrderType=Market Quantity=10 LimitPrice=0 StopPrice=0 SignalName='IntraDn' FromEntrySignal=''

They are followed by my first nine Print lines (as before).

Note the times are the same as I reported before: the third differs from the first two by 17 seconds. No new information.

[NinjaTrader_JoshP]

mikeyork,

1. Exchange latency, internet latency, brokerage latency, data feed latency, delays can come from anywhere. For backtesting, you can only submit orders at the NEXT new bar. If the timestamp of the next new bar is 17 seconds later then that is what happens.

2. The time stamps do show you when the order happened. What doesn't happen is they don't have to print out in order. Trying to match them based on the sequence they come in at will not work.

3. If you actually had a duplicate order it will take a different unique token. Only order amendments can have any impact on the existing order. You likely have a logical flaw in your code somewhere where it is resetting your IOrder prematurely.

4. The sequence, submitted->accepted->working, etc. is guaranteed. You are guaranteed to receive them eventually. What is not guaranteed is when you try something like this OnOrderUpdate for entry1 -> entry1 = working -> OnOrderUpdate for entry2 -> entry2 = working. -> try to check entry1 for working to determine if both are working and then do something. That will not work. entry1 can already be in a Filled state.

[mikeyork]

mikeyork,

1. Exchange latency, internet latency, brokerage latency, data feed latency, delays can come from anywhere. For backtesting, you can only submit orders at the NEXT new bar. If the timestamp of the next new bar is 17 seconds later then that is what happens.

As I have already stated several times. I submit all three orders on the same bar. How do they get different time stamps? What happens between my submitting the order and it getting its time-stamp? If there is some dependency on the next bar for each instruments, then note that my bar period on these instruments is one tick. I think it very unlikely that ticks will be 17 seconds (even minutes in some cases) apart. It may happen once in a while when there is sparse trading, but not consistently like I am seeing.

2. The time stamps do show you when the order happened.

What does "happened" mean?

[NinjaTrader_JoshP]

mikeyork,

Yes, you submit them at the same bar, BUT, especially since you are backtesting, it doesn't care that you submit them at the same time. It can only act at the beginning of the NEXT bar of each instrument. If the next bar does not begin till 17 seconds later. That is that. From your outputs it is clear that 2 of your instruments start up immediately, but your 3rd instrument doesn't have a bar until 17 seconds later. To check this you would need to just manually go through the charts and check it out. Alternatively you can use Print() and print out bar times for all of your instruments and run a comparison check from there.

Happened = sent.

[mikeyork]

"next bar" == one tick

How does a tick get to be as much as 17 seconds (or even minutes) consistently?

[NinjaTrader_JoshP]

mikeyork,

You will need to compare to actual chart data.

[mikeyork]

Duplicate post

[NinjaTrader_JoshP]

Just run a line for

Print(Time[0] + " BarsInProgress: " + BarsInProgress + " OHLC: " + Open[0] + " " + High[0] + " " + Low[0] + " " + Close[0]);

at the top of the OnBarUpdate().

[mikeyork]

Why is it necessary to wait a bar before placing an order -- particularly if bars can be of the order of minutes? I don't know of any broker that requires this. Why does NinjaTrader?

It's quicker to make a phone call!!!!

[NinjaTrader_JoshP]

mikeyork,

This is not a requirement of NinjaTrader per se. It is a requirement of backtesting in general, which is what I assumed you were doing since your log prints were all to the Back101 account. Please see this article: http://www.ninjatrader-support.com/H...TimeVsBacktest

Basically backtesting means you are NOT tradeable on your signal bar. Reason is as follows. In backtesting you have the OHLC of the bar already. Since you have the Close, that means that bar is closed. Closed bars are untradeable bars and so whatever you do has to happen at the next bar's open. In real-time this can be different, but in backtesting this is the only acceptable behavior because any placement of trades within a closed bar is essentially cheating.

[mikeyork]

mikeyork,

This is not a requirement of NinjaTrader per se. It is a requirement of backtesting in general, which is what I assumed you were doing since your log prints were all to the Back101 account. Please see this article: http://www.ninjatrader-support.com/H...TimeVsBacktest

Basically backtesting means you are NOT tradeable on your signal bar. Reason is as follows. In backtesting you have the OHLC of the bar already. Since you have the Close, that means that bar is closed. Closed bars are untradeable bars and so whatever you do has to happen at the next bar's open. In real-time this can be different, but in backtesting this is the only acceptable behavior because any placement of trades within a closed bar is essentially cheating.

Sure. But back-testing market orders with huge delays is ridiculous.

It's essential that I find out how to cut these delays (except in highly exceptional cirucmstances, like a closed market) down to a second or two at the most. This is the information I need from you. You must surely have encountered this problem before and have a solution for it.

[NinjaTrader_JoshP]

mikeyork,

You place an order at the next bar's open. Even if we did place the order at the signal bar's close it wouldn't make a difference because it would still be filled at the next bar's open. The timestamping is irrelevant because the next data point in the series is still 17seconds later. The results would be the same.

This is how NinjaTrader handles backtesting. There is nothing that can be done.

[mikeyork]

mikeyork,

You place an order at the next bar's open. Even if we did place the order at the signal bar's close it wouldn't make a difference because it would still be filled at the next bar's open. The timestamping is irrelevant because the next data point in the series is still 17seconds later. The results would be the same.

This is how NinjaTrader handles backtesting. There is nothing that can be done.

Then there needs to be an option to backtest market orders on the last close (perhaops with optional "slippage"). This is hardly "cheating" if it gives the most accurate simulation of real-time trading (as may well be the case, given your explanation).

But personally I doubt that what you say gives an adequate explanation of what is going on. The delays I am seeing are simply not realistic even in the light of your explanation. (17 seconds for the next tick on USDCHF, GBPUSD or EURUSD???)

Something else is going on here that we haven't got to the bottom of.

[NinjaTrader_JoshP]

mikeyork,

I don't know of any other way to explain this. If the next bar's open is 17 seconds later then your order will be submitted when that bar opens. There is nothing to be done differently. Even if we allowed you to submit your order at bar close it is still exactly the same thing as it is right now. It will not be processed till the next bar's open. There is no data or possible entry point before these 17 seconds. The open for this instrument is 17 seconds later and this is why your order is 17 seconds behind your other orders.

This is the end of the line for this issue. If there is no data point between the 17 seconds till the new open, nothing can be processed within that time period when doing a backtest. NinjaTrader is tick driven. No tick = no action. Your next tick is 17 seconds later. Your action will occur when that tick occurs.

You are expecting just because you submitted a market order you will get filled right when you submit it. This is unrealistic. If there is no data till 17 seconds later there is absolutely no chance you will get filled any time before that 17 seconds.

[mikeyork]

This is how NinjaTrader handles backtesting. There is nothing that can be done.

Actually, even this is not true if bid/ask are known. Back-testing can be done according to bid, ask or somehwere in between as the user specifies.