NT7 & Timestamp

[MXASJ]

murfinp and DaManJ,

I've only just started looking at sub-second data for a specific project. Out of curiosity, do you find millisecond time stamps more common or index time stamps? By index I mean within 1 second, trade data enters and is given an incrementing index number until that second ends.

I can elaborate if needed but if you are talking ms timestamps you probably now what I'm on about.

Thanks.

[DaManJ]

murfinp and DaManJ,

I've only just started looking at sub-second data for a specific project. Out of curiosity, do you find millisecond time stamps more common or index time stamps? By index I mean within 1 second, trade data enters and is given an incrementing index number until that second ends.

I can elaborate if needed but if you are talking ms timestamps you probably now what I'm on about.

Thanks.

Well NT is obviously using an index for their ticks within the 'second' period - otherwise NT wouldn't know what order they were in.
btw, Rithmic is actually microsecond timestamp, not millisecond.
Thats the second followed by 6 zeros
[IMG]file:///C:/DOCUME%7E1/J/LOCALS%7E1/Temp/moz-screenshot-1.png[/IMG]

[NinjaTrader_Dierk]

To clarify: Of course ticks (and L2 data) are processed by NT in the sequence they come in. There is no need for an index whatsoever. Seconds/milli second or micro second resolution has nothing to do with maintaining the proper tick sequence (which NT does).

[davewolfs]

To clarify: Of course ticks (and L2 data) are processed by NT in the sequence they come in. There is no need for an index whatsoever. Seconds/milli second or micro second resolution has nothing to do with maintaining the proper tick sequence (which NT does).

So why not just implement the change then

[NinjaTrader_Dierk]

Please see my posts below. Thanks

[DaManJ]

There is no need for an index whatsoever.

Then of course we can conclude that you save data in binary format (although that was obvious anyway).
If the ticks were stored in a database table (not in binary) but with a row for each tick, then yes you would need an index because tables do not have a sense of order implicitly, like a binary file does.

So I can presume the whole trouble for you, as I suggested below is the fact that you are storing in this binary format.

I suppose then I can further presume that you are doing something like:
12:01:01 tick tick tick tick tick 12:01:02 tick tick tick tick tick tick 12:01:03 etc.

you could potentially change to:
12:01:01.004453 tick 12:01:01.535235 tick etc. but then I suppose the size of your files and access db (where you store the binary as OLEObject) would increase significantly.
I suppose also in NT7 you have not chosen to go with the better alternative of saving ticks into their own table, but instead are keeping this binary format.

How hard would it be to change though? I mean, it would only be a few lower level objects to rewrite.
It seem to me your current approach was probably trickier to implement than a db solution would have been

[NinjaTrader_Dierk]

Here are the facts again:
- tick sequence is maintained
- timestamp granularity is down to 1 second
- as of now we don't have any plans to change the granularity of the timestamps to milli or micro seconds

Unfortunately there is no further information available on that subject. Thanks for your understanding.