Second series is being feed 1 bars earlier in Multi-Timeframe Indicator ?

[ttodua]

I use have applied indicator on 1 min chart. Howerver, this indicator includes:

AddDataSeries(Instrument.FullName, BarsPeriodType.Tick, 1, MarketDataType.Last); //indi is set: OnEachTick


Lets say, when I use this:

Print(BarsInProgress + " | " + Time[0].ToString() + " = " + Close[0]);

on i.e. xx:24 minute bar (which has: OHLC : 84|86|83|85 i might see something:


0 | ..xx:24:00 = 85
1| .. xx:24:01 = 85
1| .......
1| .......
1| .. xx:24:33 = 79
1| .......
1| .. xx:24:46 = 91
1| .......
1| .. xx:24:59 = 90



So as according to that tick-series, this bar should bave been OHCL 85|91|79|90 . However, OHLC with exactly these values, is on BIP 0 on the next bar.


0 | ..xx:25:00 = 90
1| .......
1| ........


So, I assume that the Primary Timeframe bar shows the data of PREVIOUS interval (like, xx:25:00 bar, shows OHLC of xx:24:00-xx:25:00 interval).
This test happens on historical backtest, havent checked in realtime yet.
How that happens, any explanation? I hope I've explained well,

[koganam]

The order of "tick" arrival is not and cannot be guaranteed. You have to write a filter to ensure that ticks which might putatively arrive with the same timestamp on different tick series should be processed in the desired order.

[NinjaTrader_ChelseaB]

Hello TazoTodua,

Are you testing this on a 1 tick series chart?
(With a 1 tick series chart, I am not able to reproduce this behavior)

Or are you comparing TickReplay to a 1 added tick series?

[koganam]

The order of "tick" arrival is not and cannot be guaranteed. You have to write a filter to ensure that ticks which might ****tively arrive with the same timestamp on different tick series should be processed in the desired order.

Are you also going to censor the word re-p-u-t-a-tion, because it contains what is a pejorative word in Spanish. So why are you censoring p-u-t-a-tive? This is ridiculous, or is it just that your censor's understanding of English is so poor that he censors a word simply because he is too ignorant to recognize the word?

[koganam]

Hello TazoTodua,

Are you testing this on a 1 tick series chart?
(With a 1 tick series chart, I am not able to reproduce this behavior)

Or are you comparing TickReplay to a 1 added tick series?

Try it on a 30m chart with a secondary series of 1 second. It should show up soon enough.

[NinjaTrader_ChelseaB]

Hey koganam,

Are you also going to censor the word re-p-u-t-a-tion, because it contains what is a pejorative word in Spanish. So why are you censoring p-u-t-a-tive? This is ridiculous, or is it just that your censor's understanding of English is so poor that he censors a word simply because he is too ignorant to recognize the word?

This was automatic by the forum software. An actual person wasn't censoring this :-). I've let our IT know about it.


When you mention:

Try it on a 30m chart with a secondary series of 1 second. It should show up soon enough.

Are we comparing ticks with each other?
If not, are we trying to compare the time of a tick to the close of a bar using a different bar type and interval?
If so, I'm not clear on why it would be expected that ticks would have the same time stamp as a completely different bar type and interval.

TazoTodua,

Below is a link to a video showing when adding a 1 tick series on a 1 tick series chart, the ticks time and volume match.
https://drive.google.com/open?id=1cF...pNARs-vMvYv6tB

[ttodua]

To start with the TickReplay, i might misunderstand the meaning. Do you call that "OnEachTick" or you call that MarketReplay?

To mention, yes, I used MarketReplay to check things that day. But as i said, i face that problem in MarketReplay.
(Thanks koganam, but i dont understand Tick arrival is not just "not guaranteed", but seems very organizely obtained, but the problem is different that i will describe again).

No Chelsea 1itick vs 1-tick is not a problem i think. All I want to say is simple (I've seen other programmer, confirming this problem), that when usind AddDataSeries(1-tick) , 1-tick data processed between `X` and `X+1` bar (meaning that CurrentBar is still X, and on chart, you see that bar has High i.e. 1234 and low i.e. 1230), then you will see that values are the HIGHEST and LOWEST values of the tick data that was processed on previous (`X-1`) bar (within BIP=1).

My example code demonstrates that well.
If you run the script in MarketReplay (with OnEachTick), you will see the problem. If you want me, I can record a screencast, and provide a simple code to backtest easily.

[NinjaTrader_PatrickH]

Hello TazoTodua,

Thank you for your response.

As I review this case can you clarify here on the following?

You are viewing the 1 Tick timestamp and seeing that it's values are actually going into the 1 Minute bar where it's timestamp is ahead of the current tick?

I look forward to your response.

[koganam]

Hello TazoTodua,

Thank you for your response.

As I review this case can you clarify here on the following?

You are viewing the 1 Tick timestamp and seeing that it's values are actually going into the 1 Minute bar where it's timestamp is ahead of the current tick?

I look forward to your response.

I have seen this many times, because all my backtesting/optimizing uses a 1-second timeframe for entries and a slower timeframe for qualifying the setup. It is very simple. Just create an strategy (actually it will show up in an indicator too), that adds a second bar series of 1 second and use a BarInProgress filter to print out the bar times as they close. You will pretty soon see a 1-sec tick that registers before the 30m tick (for example, you will see a 1000:01ET tick on the 1-sec bar series register before the 1000 ET tick on the 30m bar. (Of course if you are using MT, then that is the timezone that should be under reference). That is just an illustrative example. It can happen at any time, and is completely unpredictable.

It wreaks havoc with the testing if one does not write code to handle it so that action is taken on the secondary bar series only after receiving the triggering tick on the primary bar series.