Behaviour of Calculate vs Real Time vs Ticks

[jeronymite]

In a Strategy, OnBarUpdate is called as determined by the Calculate setting.

It seems in all cases, no matter what the Calculate setting, OnBarUpdate is triggered only when the first tick arrives after the real-time end of the Bar in progress.

For example, if the BarsPeriod is 60 Minutes and the 60 Minute real-time period elapses (i.e. the top of the hour arrives), if the market is very slow and the next tick does not arrive for, say, 2 Minutes (an exaggerated period perhaps, but still possible), OnBarUpdate will not trigger until 2 minutes after the hour.

This example is of little consequence for Calculate.OnEachTick and Calculate.OnPriceChange, since these both are explicitly tick-dependent.

For Calculate.OnBarClose though, it is more problematic, since one can interpret BarClose as "the real-time period of BarsPeriod has elapsed NOW in real-time". This is not tick-dependent. In this case, I would contend that triggering OnBarUpdate should be tied to real-time, not the next tick after the elapsed real-time. That is certainly my view of the "correct" behaviour.

If NinjaTrader agrees this is indeed the behaviour that occurs (please correct me if I have misunderstood anything), I believe there should be (at least) two changes to make the behaviour more able to cater for real-time requirements:

1. An additional Calculate setting of Calculate.OnRealTimeElapsed is warranted. The behaviour would be to trigger OnBarUpdate in real-time as the BarsPeriod elapses.
2. With such a new Calculate setting, the closing Bar should be closed/completed in real-time, not when the next tick arrives, and all Bar attributes (OHLC etc) should be immediately available.

Grateful for comments and consideration of the recommended changes.

Thanks.

[bltdavid]

For example, if the BarsPeriod is 60 Minutes and the 60 Minute real-time period elapses (i.e. the top of the hour arrives), if the market is very slow and the next tick does not arrive for, say, 2 Minutes (an exaggerated period perhaps, but still possible), OnBarUpdate will not trigger until 2 minutes after the hour.

NinjaTrader is an event driven system.

The portion in red is the expected behavior.

If you're wanting to make a trade when the bar closes, and the bar actually closes
2 minutes after the top of the hour (using your example) -- well, that's not a big deal,
because zero trades happened during those 2 minutes anyways, right?

If you need to take action at the precise top of the hour, you'll need to use a Timer.

[jeronymite]

Thanks, bltdavid .

Yes, all understood, and it is certainly one way to go.

It really comes down to the interpretation of OnBarClose, I suppose. When, technically, does the Bar Close, and therefore at what point is the Bar "Closed" and all data on the state of the Bar available, as well as when BarClose actions should be automatically invoked?

In the example given, what is the state of the Bar data at the top of the hour compared to when a tick arrives after that and the Bar is definitively Closed? OHL would be the same, presumably, but C (Close) would not be defined in that context, if one strictly follows the logic of the Bar is not Closed until the tick arrives. Of course, one could use the Last tick price and treat it as Close, but the relevant Data Series would not have a defined value, I suspect. That would make use of standard capabilities that use the Close Data Series problematic if one wants to use those data after the real-time elapses but before the Close tick arrives.

Thanks.

[bltdavid]

Thanks, bltdavid .

Yes, all understood, and it is certainly one way to go.

It really comes down to the interpretation of OnBarClose, I suppose. When, technically, does the Bar Close, and therefore at what point is the Bar "Closed" and all data on the state of the Bar available, as well as when BarClose actions should be automatically invoked?

In the example given, what is the state of the Bar data at the top of the hour compared to when a tick arrives after that and the Bar is definitively Closed? OHL would be the same, presumably, but C (Close) would not be defined in that context, if one strictly follows the logic of the Bar is not Closed until the tick arrives. Of course, one could use the Last tick price and treat it as Close, but the relevant Data Series would not have a defined value, I suspect. That would make use of standard capabilities that use the Close Data Series problematic if one wants to use those data after the real-time elapses but before the Close tick arrives.

Thanks.

Yes, Close is absolutely defined in that context, it has a value, and is
accessible via Close[0] with OnEachTick.

What I mean is, if you're using OnEachTick, the OHLCV values at the
top of the hour are the bar close values. Those values will be the same
values 2 mins later when the first tick arrives to start the next bar. Why?
Because the first tick of the new bar does not count for the previously
closed bar (the volume of this tick is obviously for the new bar), and,
for ever so brief a moment, it is an absolute given(*) that, on the first tick
of the new bar, we have same price for each price point (O=H=L=C).

Think about it,
Using OnEachTick, consider when IsFirstTickOfBar is True at 2 mins
into the bar, ie, you get the first tick. At this point Close[1] is the close
price of the previously closed bar. But during the 2 min period when
no ticks arrive, Close[0] is also that same price.

[(*) Well, maybe not 'absolute given', but it sure seems like it might be.]

[bltdavid]

If you think about the considerations that the NT engineers had to make, if they
define the 'BarClose' event to be the 'arrival of the first tick of the next bar' they
have effectively and efficiently addressed all 'BarClose' events cases for all bar
types. The time stamps in the Time data series for 60min bars don't need to
reflect that the first tick of the next bar was 2 mins late -- the timestamp is at
the top of the hour, even if no ticks occurred there, even if no BarClose event
occurred there (because it occurred 2 mins later) -- but I say again, what does
it really matter? Zero ticks for two minutes means no one on the entire planet
placed a market buy/sell order, so you've missed nothing.

[bltdavid]

I think, if you code it carefully enough, you already have all you need.

The 'BarClose' event is absolutely not going to change, it is defined
as 'the arrival of the first tick of the next bar'. And this transition is
well-documented and there is a lot of support (ie, IsFirstTickOfBar,
CurrentBar) to recognize this event, both with and without OnEachTick.

Given that support, now consider that at the exact top of the hour,
all of the data series for OHLCV values are already correct and
up-to-date. I mean, with OnEachTick, all values at '[0]' are always
kept current, right? -- so they reflect the correct values at each tick
for the active bar currently being built. Thus, one millisecond after
the top of the hour, Close[0] is already at its final value, and so is
Volume[0].

The OHLCV data series haven't transitioned/shifted to the next bar
yet because the BarClose event hasn't happened -- we're still waiting
for that first tick after the top of the hour -- but, no matter, you have
all you need right there in the '[0]' values.

When the first tick of the new bar arrives two mins later, all
data series value shift, and the closed bar is accessible at '[1]',
and the '[0]' represents the brand new active bar being built,
which is getting started 2 minutes late -- this all happens internally
on that first tick of the new bar, which (for us) is just before
OnBarUpdate is called w/IsFirstTickOfBar=True.

So, like I said before, consider using a timer if you want to act at
the close of the hour vs the close of the bar.

I suspect it's easy to detect this 2 min 'ghost' period where a bar
hasn't officially closed (because the 'BarClose' event needs that
first tick of the new bar) -- so if you setup a timer for the top of
the hour, or better, maybe 1 millisecond after, you should be able
to use the '[0]' values with confidence if you detect you're inside
a ghost period.

[NinjaTrader_Kate]

Hello jeronymite,

Thank you for your post.

As he usually does, bltdavid hit the nail directly on the head here. OHLCV values remain the same whether the tick to open the next bar comes in at precisely the clock time you'd expect or 2 minutes later. As no trades were made during the prior 2 minutes, it doesn't matter price wise if your orders are triggered exactly at the time you expect the last bar to have closed or 2 minutes later.

Please let us know if we may be of further assistance to you.