data sycnronized in real time?

[greentrader]

Sorry if this has been asked before...

For a strategy with multiple instruments, and called only on bar closes, and working in realtime, does NT wait until ALL bars for ALL the instruments have been closed before making any call to OnBarUpdate?

In other words, will an OnBarUpdate call ever occur for one instrument while the data for another instrument is not yet available for that minute? Or can I safely assume that all the bar data is available for all instruments when OnBarUpdate is called in realtime for the last closed bar?

Does this also mean that such stategies can get delayed if any one of their instruments has a delay in its data reporting?

[NinjaTrader_JoshP]

Nope. OnBarUpdate() will fire independently of the others. With CalculateOnBarClose set to false you can even get it to fire every tick.

[greentrader]

Nope. OnBarUpdate() will fire independently of the others. With CalculateOnBarClose set to false you can even get it to fire every tick.

Umm, not sure which question you're answering...

Are you saying that, for a strategy with AAPL and MSFT instruments, both set for 1 minute bar data, and called only on Close, that it's possible to get a call for an AAPL close while the MSFT close on the same bar has not yet occurred (in real time)? If true, that would make the logic of many of the example strategies flawed, since they do not account for this possibility.

That would mean that I will have to track the state of each instrument's last bar before using it in strategy logic. That doesn't sound right.

------------
A related question: For the above case, are the calls to OnBarUpdate made on the same thread, in sequence? And if so, is the sequence well-defined?

------------
The example given for the Add() method illustrates the problem:

protected override void OnBarUpdate()
{
// Ignore bar update events for the supplementary Bars object added above
if (BarsInProgress == 1 || BarsInProgress == 2)
return;

// Go long if we have three up bars on all bars objects
if (Close[0] > Open[0] && Closes[1][0] > Opens[1][0] && Closes[2][0] > Opens[2][0])
EnterLong();
}

So the question is, what is the real status of "Closes[1][0]" and "Closes[2][0]" if we're being called only on bar closings? Are these the actual Close values for these bars, or are they just the most recently trades prices for those instruments?

[NinjaTrader_Ray]

Good observation.

In real-time, yes, bars could not be in sync. That is the nature of multi-instrument strategies. There is absolutely no way to ensure that both APPL and MSFT 1 minute bars have closed before throwing OnBarUpdate() event. In a backtest, that is of course different.

There is no sequence. OnBarUpdate() is called when tick for a bar series comes in. Regarding the same, thread, development will answer this early next week since they are out right now.

Your last question, they are the close price of the last closed bar.

[greentrader]

Good observation.

In real-time, yes, bars could not be in sync. That is the nature of multi-instrument strategies. There is absolutely no way to ensure that both APPL and MSFT 1 minute bars have closed before throwing OnBarUpdate() event. In a backtest, that is of course different.

There is no sequence. OnBarUpdate() is called when tick for a bar series comes in. Regarding the same, thread, development will answer this early next week since they are out right now.

Your last question, they are the close price of the last closed bar.

Thanks for the further info. I can work around these issues, but I didn't want to have to do a lot of experimenting to figure out how stuff worked.

From answers to an earlier question I submitted in another thread, my impression is that the current bar is not considered closed until data starts arriving for the next bar - which is why daily-based EMAs based on indices don't calculate today's EMA before tomorrow's open, when data for the next bar starts arriving.

With respect to the last question, I am surprised that the other instruments will report the close of the last closed bar, rather than the last price traded within the current minute. That means that one really does have to take the trouble to make sure all the bars have been closed before making use of them across instruments.

With respect to the thread question, my concern is that if I try to fix the lack of synchronization by imposing my own logic (such as by counting the instruments becoming closed, and then reacting when they're all closed), that my logic may not work if the OnBarUpdate calls can be done asynchronously (i.e., at the same time). I doubt if that's possible, given the connection of strategies to the UI, but would be good to confirm.

BTW, from experience with TradeStation, in the case where indicators are marked to only be called on bar close, and more than one instrument is involved, then TradeStation waits until all the data has arrived before calling the indicator, even if this means delaying the call. This greatly simplifies coding, although the delay can be a nuisance if many instruments are connected to the indicator. Anyway, something to consider if you're going to open the door wider to even more support for multiple instruments.

Thanks again for the info.

[NinjaTrader_Ray]

Sorry, my fault. OnBarUpdate() is synchronous of course.

- If you want the last price traded then run with CalculateOnBarClose = false. You can then monitor for the close of a bar via the FirstTickOfBar property. When this is true, a tick has arrived for the new bar, which marks the close of the prior bar. Then any values you check are in the context of the last incoming tick

- Delaying OnBarUpdate() I am not sure is a valid idea since theoretically, you could have it delayed for an inifinte amount of time if you have an instrument that does not have a tick for some time.

[greentrader]

Sorry, my fault. OnBarUpdate() is synchronous of course.

- If you want the last price traded then run with CalculateOnBarClose = false. You can then monitor for the close of a bar via the FirstTickOfBar property. When this is true, a tick has arrived for the new bar, which marks the close of the prior bar. Then any values you check are in the context of the last incoming tick

- Delaying OnBarUpdate() I am not sure is a valid idea since theoretically, you could have it delayed for an inifinte amount of time if you have an instrument that does not have a tick for some time.

Okay, so I'll try to fix this problem by counting the bar closings seen by OnBarUpdate, and then reacting when the last one shows up (vs. giving up performance by getting all ticks).

It would be nice to have a check box option to have NT do such a thing for us in the case where CalculateOnBarClose is true. It's true that OnBarUpdate would not then be called if any one of the instruments got stuck, but this is already true for each individual instrument, so it's not really a big problem - the trader is simply saying that they don't want to react until they have all the bar closings. Anyway, something to consider, especially if NT is going to open the door to multi-instrument support in indicators.

Thanks again for the helpful responses.

-------------
Okay, so the way it should work is that there is an option that has NT delay calling OnBarUpdate until all the bars for all instruments in that strategy/indicator have closed for that time period (if CalculateOnBarClose is true). In this case, OnBarUpdate could also only be called once for the primary instrument, since all the bars would be closed for the other instruments. This would both greatly simplify programming and reduce the number of calls to OnBarUpdate when CalculateOnBarClose = true.

[NinjaTrader_JoshP]

Implementing this would introduce considerable lag times to strategies utilizing less volatile instruments. The current implementation allows the trader maximum flexibility in how their strategy behaves, but thanks for the suggestion. We will definitely add it to the list of future considerations.

[greentrader]

Implementing this would introduce considerable lag times to strategies utilizing less volatile instruments. The current implementation allows the trader maximum flexibility in how their strategy behaves, but thanks for the suggestion. We will definitely add it to the list of future considerations.

I don't think that the option I suggested above removes any flexibility. And I'm not sure why you think it introduces lag time. The only lag time (for the trader) is the time it takes waiting for all instruments to close in the current bar, but that's the tradeoff for someone who does not want their code executed until all data is available for that bar. In fact, if the only call made to OnBarUpate is to the primary symbol, then this saves time.

For example, lets say someone wanted to calculate a realtime "index" based on 10 stocks as part of their strategy (or future indicator). They would set CalculateOnBarClose to true, choose the option to not be called until all instruments have closes for the current bar, and then link the 10 stocks to the indicator using "Add". NT then goes about its business as usual, but, based on the option checked, does not call OnBarUpdate until all 10 closes are available (and then only calls it once). The strategy then calculates its index based on the 10 closes, and bases its response on that.

Doing it the current way, I would have to wait for OnBarUpdate to be called 10 times(!), ignoring 9 of the calls, before calculating the index. That's a waste of processing time (and support time, having to explain all that to traders).

Also, without supporting the suggested option, the current example code for multi-symbol support is broken, since it doesn't account for the fact, when comparing instrument prices, that one or more of the prices may not be what you think it is (i.e., is from a previous bar). So, if anything, the suggested option makes more sense as the default setting to use when CalculateOnBarClose = true. (And, as I described earlier, that's what Tradestation does, since they ran into this same issue long ago.)

Anyway, as a .NET programmer I like NT, and just want to see it succeed if I'm going to make extensive use of it. Thanks for all the help dealing with these issues.

[NinjaTrader_JoshP]

The lag of waiting for all instruments is the lag I was referring to. Under most circumstances people seem to want to get the latest info on any of the instruments immediately as it happens. If the MSFT closes first, they don't want to wait for AAPL to close before knowing MSFT closed already. The flexibility is in that having it this way if you wanted to wait for AAPL to close before doing anything with MSFT you can program to do this, but if you wanted to act immediately on MSFT you can do that also.

[greentrader]

Okay, all I can say is to look more closely at the examples I gave in my previous post (the index calculation and NT's own sample code). The suggested option would deal with these cases in a very simple way, without removing the flexibility of using the existing approach.

After unleashing multiple instruments on indicators, I bet you guys come around to seeing the wisdom of the suggested option (having been living with this on TradeStation for many years), so I'll just shutup about this for now. Take care, and thanks again for all the help and insights.