The OnMarketData() method is guaranteed to always be called before OnBarUpdate()

[NinjaTrader_Brett]

np, you can assume CurrentBar in OnMarketData will be in sync with OnBarUpdate. To explain further:

Per my slide below, as tick #6 comes in this is the event that closes the now previous 5 tick bar. We call OnBarUpdate and then OnMarketData in that order as tick #6 comes in. So OnBarUpdate runs on CurrentBar pointer is incremented to next bar and OnMarketData current bar will be correctly updated as OnMarketData runs for that Tick #6 since it truly belongs to the next bar.

I will consider adding something to OnMarketData stating this.

-Brett

[roman_ch]

Brett,

Thanks for the below. Please can you clarify: in your slide, the bottom sequence shows the "orange" tick 1 arriving first in OMD and only then in OBU (that is, when we are using OnEachTick). I thought that the OBU for tick 6 will run before OMD for tick 6 only if Calculate OnBarClose?

If the slide sequence is correct then lagging CurrentBar does occur in OMD for Calculate OnEachTick. Please let me know if I misunderstood.

Regards,
Roman

[joanrocagas]

No offense intended, Brett. I really appreciate the effort put into the slide, but I found it very confusing.

The only thing I'm certain after testing NT8 in several ways is that on Calculate OnEachTick
OBU executes before OMD for every tick.
OMD will have the CurrentBar value in sync with the market.
OBU method doesn't have the MarketUpdate object. You have to wait to next OBU. That's why OBU lags one tick.
OMD has access to MarketUpdate. OMD will be in sync with the market.
You are happy with OBU lagging one tick, or otherwise OBU is a useless method.

That means, that I put all the logic in OMD. Leave OBU method empty. OBU method lags one tick all the time.

In Calculate onBarUpdate it happens a similar thing, because the indicator has to wait until the first tick of the next bar to update the previous bar. Really weird design.

One question I really don't know the answer is why this was done this way.

Why OBU has to wait to the first tick of the next bar?? This seems the root of the problem to me.

[NinjaTrader_Brett]

Roman,

I edited the slide to more clearly point out what is going on with CurrentBar pointer by color code. I also resolved an issue I had with the slide so I will delete the old one. This should clear things up let me know if more questions.

Joanrocagas,

NinjaTrader 7 and NinjaTrader 8 both wait until the next tick of the next bar to close the previous bar. This is intended since for example lets say you have a 1 minute bar, as ticks come in for the current minute all is great you keep applying them to the current 1 minute bar. Now lets say the minute is done and there are no ticks coming in since the market is slowing down. The next tick doesn't come in for another 10 seconds into the next 1 minute bar. This is the tick event which signals that the previous bar is closed and this tick belongs to the next bar. NinjaTrader is truly event based from ticks, there is no synthetic 'close the bar right at the top of the minute' event, and we would not want to introduce one either since then the time sync of the local PC clock will change the number of ticks included in each 1 minute bar and no two 1 minute charts generated from different computers with different time syncs will be the same. Hopefully this sheds some light into why it is designed as it is, there are other reasons as well but this is the most clear cut one.

-Brett

[joanrocagas]

Joanrocagas,

NinjaTrader 7 and NinjaTrader 8 both wait until the next tick of the next bar to close the previous bar. This is intended since for example lets say you have a 1 minute bar, as ticks come in for the current minute all is great you keep applying them to the current 1 minute bar. Now lets say the minute is done and there are no ticks coming in since the market is slowing down. The next tick doesn't come in for another 10 seconds into the next 1 minute bar. This is the tick event which signals that the previous bar is closed and this tick belongs to the next bar. NinjaTrader is truly event based from ticks, there is no synthetic 'close the bar right at the top of the minute' event, and we would not want to introduce one either since then the time sync of the local PC clock will change the number of ticks included in each 1 minute bar and no two 1 minute charts generated from different computers with different time syncs will be the same. Hopefully this sheds some light into why it is designed as it is, there are other reasons as well but this is the most clear cut one.

-Brett

thank you for the explanation, Brett.

let me understand it better. I'm using the IQFeed API myself too, and I know that IQFeed sends the market timestamp with every tick message.

So does your explanation mean that NT8 relies only on the timestamp supplied in every tick by the data provider in order to assign every tick to its corresponding bar?

Relying on the local clock to close the bar would render different bars on different computers, right?


Is MarketDataEventArgs.Time the actual stock market timestamp provided by the data provider? It's not generated by NT8, is it?

[NinjaTrader_Brett]

That's exactly correct, we only use the native provider time stamps on ticks. It allows us to build reproducible charts all the time. I'm also confirming that the OnMarketData time would be the native providers time if your provider supports that. (Most do but here is our chart of what providers support native time stamp, check the 'real-time time stamp column': http://ninjatrader.com/support/helpG...y_provider.htm)

[joanrocagas]

Ok, I fully understand the problem. Thank you, Brett.

As a new user of NT, I was really confused by these two methods. I think it should be explained much better in the docs this small detail. OBU executes on the first tick of the next bar.

It might not make much difference to some, but I rely a lot on tick based indicators and I needed to fully understant how OBU and OMD methods work together.

[gomifromparis]

In OnBarClose mode, what would be needed is a OnBarClosing event which is triggered once all the OMD data is processed and Ninja is ready to open a new bar. Just before the next OBU.

That what way you are able to update the current bar using this event with the correct values computed with all the ticks received.

[BraisedInBlue]

Not to revive an old thread, and not to argue design semantics of NT. But the suggestion posted above is exactly what could be useful to clarify/rectify these issues. This is a common design pattern in modeling and simulation. FrameBegin(), FrameMiddle(), FrameEnd() events tied to whatever time-series granularity you are privy to. So if you have a 30 second deltaT, FrameBegin is fired at the open of a new timePeriod, and likewise FrameEnd is fired at the end, prior to the new opening period. I think alot of this is semantics, but it makes code design and maintenance cleaner, because specific types of tasks reside in these categories and it makes it harder to be "out of sync" conceptually.