Bug MultiTimeFrame 1-Tick

[cls71]

Hello,

I am using two timeframes for the FDAX 09-17 with Calculate = OnBarClose:
- Primary (chart) = 30 sec
- Secondary = 1 tick

I am observing in real time that the OnBarUpdate method of many 1-tick bars are executed after the OBU method of the 30-sec bars, although its timestamp is earlier and should be executed earlier.
However, with historical bars works well, and the sequence is correct.

Attached a simple script to test it.

[NinjaTrader_ChrisL]

Hello cls71,

Thank you for the post.

I am reviewing your inquiry and will be back with a reply shortly.

I look forward to assisting further.

[NinjaTrader_ChrisL]

Hello,

Thank you for your patience.

This is expected to happen. Multi-series scripts running on tick series do run a chance of peaking into the future. Since the series are synced by timestamp down to a 1-second granularity you can run into the following issue:

note* BIP = BarsInProgress

Consider BIP0=5tick, BIP1=1tick. Marked below is the BIP0 bar and its corresponding BIP1 bars.
BIP0 10:00:00
BIP1 10:00:01 ___
BIP1 10:00:02 ___
BIP1 10:00:02 ___
BIP0 10:00:03 ___
BIP1 10:00:03 ___
BIP1 10:00:03 ___
BIP1 10:00:03
BIP1 10:00:04

Since BIP0 and BIP1 are synced to timestamp we see the BIP0 print first at 10:00:03. This print comes before the 5 ticks of the BIP0 bar were processed yet in the BIP1 context. Implications = BIP0 was processed containing info from the future two ticks. Then after BIP0 processes, we process those two ticks in BIP1 that would complete the BIP0 bar.

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

[Harry]

Hello,

.... Since the series are synced by timestamp down to a 1-second granularity you can run into the following issue:

note* BIP = BarsInProgress

Consider BIP0=5tick, BIP1=1tick. Marked below is the BIP0 bar and its corresponding BIP1 bars.
BIP0 10:00:00
BIP1 10:00:01 ___
BIP1 10:00:02 ___
BIP1 10:00:02 ___
BIP0 10:00:03 ___
BIP1 10:00:03 ___
BIP1 10:00:03 ___
BIP1 10:00:03
BIP1 10:00:04

...

It was my understanding that the series are synced down to microsecond granularity. You are talking about a 1-second granularity here. Didn't this improve with NinjaTrader 8?

[NinjaTrader_ChrisL]

Hello cls71,

Thank you for the reply.

There is a fundamental difference between tick and second bars. Tick bars are not time dependent so they are asynchronous with data series that are time dependent. When one second has passed, the second series current bar must close, causing an OnBarUpdate to occur.

From the help guide section on Multi-series scripts:
"In reality, both bars series are incrementing in their exact sequence according to the timestamps of each series."

https://ninjatrader.com/support/helpGuides/nt8/en-us/?multi-time_frame__instruments.htm

So what is happening is the 1 second bar is closed after 1 second, so OnBarUpdate is called for the 1 second data series, but there was tick data for 10:49:58.406, so NinjaTrader is not going to skip this tick bar because the 1 second series has moved on. NinjaTrader will print the timestamp of this tick bar even though the timestamp of the 1 second bar has moved on.

Please let me know if I may be of any further assistance.

[cls71]

As far as I know, a bar closes when the first tick of the next bar is received. (A bar closes when the AddBar is executed within the OnDataPoint method of your BarsType.)
So a bar of eg 30 seconds can close even many minutes after when it would correspond for time if the market is stopped.

I suppose the reason for all these desynchronizations we are talking about is that first tick of the next bar.

In the image I uploaded, there were two ticks with the same timestamp = 10: 49: 58.406 with VOL = 2 and VOL = 1. What I do not understand is why one runs before the OBU of the 30-sec bar and another one after.

What I've checked is that the last 1-tick that corresponds to a bar always runs after, in the next bar. Just the last tick, and only in real time. In historical it is not so.
I have also found that NT 7 works the same, so it is not a bug.

As long as it works in this way, the supposed desynchronization can be solved by code: in real time,when the closing of the 30-sec bar is detected, wait for the first 1-tick OBU to execute the calculations. In this way the volumes of the 30-sec bars and the accumulated from the 1-tick bars always coincide.

[cls71]

I rectify my previous comment. With Range bars fails.

I'm using this scenario:
Primary TimeFrame ES 09-17 2-Range
Second TimeFrame ES 09-17 1-Tick

I attached an image to explain the problem.



The code to test is as simple as this:

...
else if (State == State.Configure)
{
     AddDataSeries(BarsPeriodType.Tick, 1);
}

...

protected override void OnBarUpdate()
        {
            NinjaTrader.Code.Output.Process(
                    String.Format("{0}   close = {1}     VOL = {2}     Time = {3} . {4}          Now = {5} . {6}",
                    BarsArray[BarsInProgress].BarsPeriod.ToString(),
                    Close[0],
                    Volume[0],
                    Time[0].ToLongTimeString(),
                    Time[0].Millisecond,
                    DateTime.Now.ToLongTimeString(),
                    DateTime.Now.Millisecond
                ), PrintTo.OutputTab2);

            if (BarsInProgress == 0)
            {
                NinjaTrader.Code.Output.Process(string.Empty, PrintTo.OutputTab2);
                NinjaTrader.Code.Output.Process("#################################################################", PrintTo.OutputTab2);
                NinjaTrader.Code.Output.Process(string.Empty, PrintTo.OutputTab2);
                NinjaTrader.Code.Output.Process(string.Empty, PrintTo.OutputTab2);
            }
}

[NinjaTrader_ChrisL]

Hello cls71,

Thank you for the follow-up, very helpful information.

The two Data Series objects in this indicator are discrete from each other. Your range bars are completely independent of your tick bars. The ticks from the secondary tick series have their own time stamps and are processed based on those time stamps (with Tick Replay enabled).

Unless you have Tick Replay on, the secondary data series will always process after the primary data series.

Tick Replay works to simulate the ticks as if they occurred in real time, hence the name Tick Replay.

You may read more on tick repay here:

https://ninjatrader.com/support/helpGuides/nt8/en-us/?tick_replay.htm

To enable the Tick Replay option, go to Tools>Options>Market Data>"Show Tick replay"

Now you will see an option to enable Tick Replay in your Data Series window.

1. First, remove the indicator in question from your Range 2 chart.
2. Right click your Range 2 chart>Data Series>'Tick Replay'
3. Now add the indicator to your Range 2 chart (or the test code you sent me). And you will see the Range 2 bars closing at the proper time.

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

[cls71]

Hello Chris,

Thanks for your answer.

The two Data Series objects in this indicator are discrete from each other. Your range bars are completely independent of your tick bars.

But how can they be independent, if the range bars are formed from tick bars ???

The ticks from the secondary tick series have their own time stamps and are processed based on those time stamps (with Tick Replay enabled).

Unless you have Tick Replay on, the secondary data series will always process after the primary data series.

Tick Replay works to simulate the ticks as if they occurred in real time, hence the name Tick Replay.

It does not matter with TickReplay. Still not working well.

Here I put another example with more historical bars in NQ 09-17 today and TickReplay enabled.

There are three ticks with the same timestamp. How can two be executed before the OBU of the range bar-4, and the other one after ???




In the end it all boils down to one question:
In NinjaTrader is it possible to use a 1-tick secondary timeframe to perform intrabar calculations of any primary timeframe ???

Thanks

[NinjaTrader_PatrickH]

Hello cls71,

Thank you for your patience.

A bar is closed when the tick that opens the next bar is received. In order of the ticks received when using Calcualte.OnBarClose you should expect to see the primary bar series close with it's timestamp yet the 1 tick secondary series could show a timestamp before the primary bar series timestamp. This occurs as the OnBarUpdate processes the data in the order received. The primary bar series has received the same tick that the secondary 1 tick bar series has, but the primary series knows that a tick exists beyond the current one and uses the timestamp of that tick, unless it's a time based primary series then it will use the timestamp that it would close at.

The behavior you detail throughout this thread is expected when comparing a smaller granularity secondary series to a larger primary series on the close of the bar.