How "Simulation" works as a connection vs. "Live"

[QuantKey_Bruce]

There have been a number of statements since 8.1 was released so I'd like to confirm some things officially and make sure that our understanding is right. This is our understanding of how the connection "Simulation" works with multi-provider mode checked OR when selecting Simulated at sign-in if multi-provider is not checked. Please correct me if any part of this is not absolutely 100% accurate because I'm trying to understand this completely unambiguously. All of this is based on previous NinjaTrader staff posts but not all of them are completely clear or I might have misunderstood so I might have some part of this wrong and that is why I am asking. Please read all this very carefully and make sure it is right.

(1) If you have just signed up for a new account at account.ninjatrader.com and are in the 14-day trial, you get non-delayed, real time "real" market data. It is not simulated data (like the simulated data feed) and is identical to the market data you would receive on a live account with a paid market data subscription. Your historical data is the same as everyone else's, and comes from NinjaTrader's servers.

(2) If your 14-day trial has expired and you have not signed up for paid market data, you get the same "real" historical data, but your "live" data is like the "simulated data feed". It is not delayed, but is instead simulated data that does not reflect the "real" market's moves in real-time after the historical data period because it's randomly generated.

(3) If your 14-day trial has expired and you have signed up for paid market data, you get the same "real" historical data, and your "live" data is completely identical to the "live" data on a funded live trading account logged in for live trading (except that your fills are simulated).

On the LIVE side:

(4) If you have a funded trading account and are logged in for live trading, but you have not subscribed to paid market data, you get the same "real" historical data but NO real-time data - your charts do not move.

(5) If you have a funded trading account and are logged in for live trading, and you have subscribed to paid market data, you get the same "real" historical data and the same "real" live data - your charts look just like everyone else's.

And:

(6) In ANY of these cases, if you download market replay data, it is the same in all cases, and is the "real" market replay data that is identical to everyone else's.

Could you please confirm if all of this is completely 100% accurate or if there are any parts of what's written here that need to be corrected or nuances that are missed?

[NinjaTrader_RyanS]

Hello,

Please see my answers to each question below:

(1) If you have just signed up for a new account at account.ninjatrader.com and are in the 14-day trial, you get non-delayed, real time "real" market data. It is not simulated data (like the simulated data feed) and is identical to the market data you would receive on a live account with a paid market data subscription. Your historical data is the same as everyone else's, and comes from NinjaTrader's servers.

This is correct, the 14 day demo provides live data from CQG and accesses NinjaTrader's historical data servers, the same as a live account with NTB.

(2) If your 14-day trial has expired and you have not signed up for paid market data, you get the same "real" historical data, but your "live" data is like the "simulated data feed". It is not delayed, but is instead simulated data that does not reflect the "real" market's moves in real-time after the historical data period because it's randomly generated.

Once the demo expires, you receive delayed market data of 10 minutes in most cases. The feed still accesses the historical data on our servers.

(3) If your 14-day trial has expired and you have signed up for paid market data, you get the same "real" historical data, and your "live" data is completely identical to the "live" data on a funded live trading account logged in for live trading (except that your fills are simulated).

Once you subscribe to data on your account this is live data from CQG for all enabled exchanges, regardless of trading live or simulated.

On the LIVE side:

(4) If you have a funded trading account and are logged in for live trading, but you have not subscribed to paid market data, you get the same "real" historical data but NO real-time data - your charts do not move.

If not subscribed to live data you will receive delayed data of 10 minutes, while accessing our historical data servers.

(5) If you have a funded trading account and are logged in for live trading, and you have subscribed to paid market data, you get the same "real" historical data and the same "real" live data - your charts look just like everyone else's.

This feed will match the feed provided on all live/demo accounts as both feeds are from CQG and using our historical data servers.

And:

(6) In ANY of these cases, if you download market replay data, it is the same in all cases, and is the "real" market replay data that is identical to everyone else's.

Replay data comes from our market data replay servers. This should be identical from all users, however it may differ slightly from the data on our historical data servers.


Please let me know if I can expand or elaborate on any of these items.

[QuantKey_Bruce]

Thank you NinjaTrader_RyanS. Could you just please clarify why at this post https://forum.ninjatrader.com/forum/...21#post1243421 it is stated that the simulation connection is like the simulated data feed in that it is randomized? And could you please elaborate on how the replay data might differ from historical? I know this is all new in a sense so it's easy to see how some points may need to be clarified.

[NinjaTrader_RyanS]

I believe that post is a bit of confusion in phrasing the 'simulation data feed'. The simulated data feed as it is labeled in the platform is the randomly generated data feed for testing purposes. There really isn't a 'simulation data feed' as all data from demo and live usernames is live market data (unless delayed due to lack of live data subscription.

It may help to explain that the data you get from CQG does not know whether you are trading live or sim, that is dictated from the platform in the account selector. The platform is receiving the same feed from CQG regardless of if you are trading live or sim.

Market replay may differ from historical data slightly due to how it is recorded to our servers. The differences would be minor, mostly affecting tick charts as some ticks may be timestamped or aggregated into bars slightly differently base don sub second time discrepancies. I've posted to our help guide article overviewing this in much more detail if needed:

https://ninjatrader.com/support/helpGuides/nt8/index.html?playback.htm#UnderstandingHowThePlaybackWorks

[QuantKey_Bruce]

NinjaTrader_RyanS Thank you for spelling all of this out. The terminology is potentially confusing.

Could you elaborate on how market replay might lead to different tick charts vs. historical or real-time? I have read link provided under "Understanding how Playback Works" but I don't see anything in there that would explain how tick charts would differ in replay from historical. Could you clarify that part in particular please?

I can see where playback would be more accurate in synchronizing depth data, and where it would be more accurate in synchronizing bid/ask, but how could the tick bars themselves differ in this case "due to how it is recorded"?

You mention that ticks might be aggregated or grouped into bars differently due to sub-second time discrepencies... if you're storing the timestamp from the exchange, and you also have them in order, wouldn't they inherently be grouped in order regardless for both historical and market replay? So, for instance, a 100-tick bar would always have 100 consecutive ticks in it once it got started because they're stored in order regardless of the granularity of the timestamp? Please help me understand what I am missing here in thinking of it that way.

I am just trying to understand this issue more fully.

Thank you again for taking the time to elaborate on this.

[NinjaTrader_RyanS]

This is mostly due to the granularity of data time stamping market replay is able to provide vs historical tick data, as well as the fact that market replay is recorded to your machine where historical data is pulling from our servers. Since your machine and our servers aren't expected to be synchronized to the nanosecond level this can alter when ticks are aggregated into which bars/sessions.

To clarify, these are very very minute differences i am referring to, likely only affecting a handful of ticks each session if at all. I simply don't want to set the expectation that all tick charts will match 100% at all times in all situations for all users.

[QuantKey_Bruce]

NinjaTrader_RyanS Thank you - please forgive me for pressing this point but there is obviously something I am missing. Both the market replay and historical data are recorded to your servers (or is the historical data downloaded as historical from CQG? that seems less likely, since it's available immediately to the second), and then delivered to the desktop via download, are they not? So, they're both being recorded as they arrive from CQG on your side, presumeably with the full timestamp given to you and their arrival sequence. Of course, a client desktop machine and your server won't be time-synchronized perfectly - that's a given. But, if the timestamps that you received and the sequence that you received them are being stored on your side, the replay and historical data would both be in order within their own file. So when either the historical data or replay data are then downloaded to a client desktop, the data is still in order. So, could you explain how the market replay tick bars might differ from the historical tick bars? Aren't they going through the exact same processing on your side except one is saved with last/bid/ask/depth all interwoven in one file in order while the other is just last in one file in order? I appreciate your patience as I try to get this process firmly understood.

[NinjaTrader_RyanS]

Hello,

I was able to confer with our product team, and in theory market replay and historical data should match 1:1 in almost all cases. Any cases where it would not would be a local issue or an very rare case of ticks having the exact same time stamp to the nanosecond level. Again an out of sync PC clock could affect this as well due to the different granularities of the time stamps, but likely it would affect both in the same manner except for again some very rare circumstances.

In a vacuum, tick data should match between the two, but there can be many factors that cause very small differences where I can't say it will match 100% of the time for all users in all situations. On your local machine though these should match though outside of some very niche cases. I hope this helps clear up some of the questions on this matter.

[QuantKey_Bruce]

NinjaTrader_RyanS Thank you. But, why would an out of sync PC clock even be relevant to how tick bars are formed or whether the ticks are in the same bar? For a 100-tick bar, wouldn't it always be 100 consecutive ticks regardless of what the time the local PC clock says it is?

When you say there is an unlikely case they could differ because of two ticks with the same timestamp to the nanosecond, does that mean you're not storing the sequence they arrived so you can replay them in the same order and so the history will always be in the right order, but you're just storing the timestamps themselves? So, if you receive two ticks from CQG both bearing the same timestamp, you might lose track of which one arrived first? Is that the sort of very rare error you're talking about here?

And, is the timestamp that we receive the timestamp that comes from CQG or is it the time you received it from CQG?

[NinjaTrader_RyanS]

The timestamps come from CQG and are recorded/posted to our servers, and in the instance a tick has the exact same timestamp it is possible the order could differ.

As for the PC clock, if using a chart that is based on 'days to load' it is referencing a start time to start building and plotting bars. So even though it is loading tick based bars, it is referencing a time at which to start the chart. If this differs significantly from the actual session start time it could affect how the tick bars load, but again it should affect both historical and market replay the same. If using 'bars to load' this would be unaffected as it is loading a predefined number of ticks from the 'endpoint' of the chart.

I would note these are very very niche issues that won't affect most users. I simply can't say they will match 100% of the time always as if so, any instance where they do not would indicate an issue where there likely isn't one.

[QuantKey_Bruce]

That seems like good news in general. If you're recording the timestamps that CQG sends you, the only circumstance they could end up out of order would be if they send you two ticks with the same timestamp to the 100 nanosecond level (same .NET DateTime). In that case, you're saying you insert them into your database and when you get them back out again they could come out in a different order, potentially. Maybe CQG sends you more resolution than a DateTime, such as nanoseconds, and maybe you store that. There are two obvious solutions to the problem of two of them arriving with the same CQG timestamp, one of which is if you get a second one that's the same 100 nanosecond timestamp just bump it up by the minimum amount (100 nanoseconds, or 1 .NET "tick") so it isn't the same anymore, and the other of which is that the data records you're recording almost certainly have an auto-increment primary key unique id. When you do a query, just make that auto-incrementing primary key part of the query e.g. ORDER BY datetime, unqiueid so that they always come back out in the same order they went in if the timestamps are the same. It sounds like you're not doing that though?

I see what you mean, I think, about the PC clock being off, but let's say my PC clock is an entire hour fast for my time zone. So, I say I want 5 days to load, and it looks at "now" and clips off to the date part and then subtracts five days (or something like that), and then grabs all the ticks that are after that starting point. So, the only way my tick bars would differ is if my clock is so wrong that 5 days ago is in the wrong date e.g. if I started it up at 11:30 pm in actual time but my wrong clock has it as 12:30 am the next day. Right? Other than that, my wrong clock would still get me all the same tick bars from historical and from market replay, would it not? Because we're using the timestamps you have in your database, not the time my computer received them. So, the tick bars should be identical except in the extremely edge case that my PC clock being off results in a different day to start the tick sequence - which would not even be true unless I started the chart loading at close to midnight and my local clock drift pushed it into a different day.

I don't follow, though, how any of this could result in the historical being different than replay. How would historical and replay be handled differently such that one would give a different answer than the other for which ticks go into a 100-tick bar?

Thank you for bearing with me on this, as I'm trying to understand the real nuances that go into this.

[NinjaTrader_RyanS]

Correct with the PC clock analogy, and as mentioned in most cases even a very out of sync PC clock would not affect tick bars. I'm struggling to think of a realistic example, but theoretically if a tick on the ES at 4150 and a tick at 4150.25 we're received at the same time, it's possible one tick would be the 100th tick of a 100 tick bar and the next would be the first tick of the next bar. On replay these could flip since the nanosecond granularity is accounted for. If that price happened to be the high or low of those bars, you could theoretically see different OHLC values between the two.

Again i'm not certain this could ever happen in reality as two simultaneous ticks that close together would likely be at the same price in all situations.

If there are any discrepancies you are seeing between the two I would contact our support team to investigate, as it's much more likely there is a chart setting or technical issue occurring rather than encountering one of these scenarios.

[QuantKey_Bruce]

NinjaTrader_RyanS Thank you. But, it sounds like you're confirming, you're not preserving the order they arrive if the CQG timestamps are identical? So, they get potentially re-ordered after arrival if their CQG timestamps are the same? That seems like the only situation we've narrowed it down to where there might be a discrepency then between replay and historical (except for the really edge case where the PC clock is wrong and it is so wrong it affects the date the "days back" starts up.) That does seem like a very tiny case, but one that's a real possibility. The PC clock one doesn't seem likely at all unless the clock is way off and you start up the chart close to midnight local time.