Timestamps (T+S and QLink)

[grumpy]

When I open a T+S window, or when using QLink, there are timestamps available in one column (like 15:59:50). At the tick level, what are these times? Are they -

- set for the tick at the exchange, or
- set for the tick when the QCharts server farm receives them, or
- set for the tick locally when QCharts receives them?

In other words, can the timestamp be used to calculate feed lag?

Does the answer to the above question apply to ALL instruments (futs, stocks and indexes)?

This is for QCharts 5.1.0.21.

cheers,
grumpy

[Larry Marchman]

grumpy,

When a continuum(QFeed) server receives a tick from Comstock, the tick is given a timestamp of when it's written into the server database, based on the server clock.

If you receive a tick with timestamp of 12:12:12 and it's about 12:12:12/13 in reality, then that's good. If timestamp of 12:12:12 arrives at local PC at 12:12:45 in reality, that's delayed.

There are caveats though. Is the server clock equal to your local clock? If not, then that needs to be considered. I've seen server clocks clearly off by up to 10 secs from atomic time, but the mis-stamped ticks were nevertheless arriving on time...at the exact same time as broker ticks albeit with 10sec differences in timestamps. They were not delayed, just mis-stamped. Or what if the server clock was OK, but received late from Comstock?

To access data delay, I eyeball QCharts T&S and Broker T&S focusing not so much on the timestamps as primary indicator of data delay in broker or QCharts delivery, but rather I focus primarily on price and size, noticing if the exact same ticks are arriving concurrently, regardless of any clock differences.

LAM

[grumpy]

LAM, thanks for taking your time to reply.

To access data delay, I eyeball QCharts T&S and Broker T&S focusing not so much on the timestamps as primary indicator of data delay in broker or QCharts delivery, but rather I focus primarily on price and size, noticing if the exact same ticks are arriving concurrently, regardless of any clock differences.

Apart from lag time, the timestamps - if reliable - would have been one way to (semi)automatically detect missing ticks in the continuum feed (when compared to a feed I trust more). Guess I'll have to think of another way to do that.

thanks again,
grumpy

[Larry Marchman]

grumpy,

Within the context of "for all practical purposes", the clock difference caveats for continuum servers I mentioned will not be an issue. Usually, the server clocks are reasonably synched and assuming your PC clock is frequently atomic synched then tick timestamp vs local time will be a good indicator. So, we are kinda left with the old axiom of trust, but verify.

In 6.0, it's been advertised that the tick timestamps are the actual exchange timestamps. This would remove server clock integrity from the equation. I'm not sure if all the eSignal servers have been updated for this feature. There was a transition period of some yes, others not as yet.

Jay, what's the 411 on the current state of 6.0 tick timestamps?

LAM

[JayF]

There are still some historical intraday data servers that need to be upgraded to fully support the exchange-based timestamp model, however all the servers that handle the streaming data have been upgraded. The result is that the data that flows in from the time you request a symbol and going forward... that data is time-sync'd with the exchanges time-stamp; historical intraday bar data may not be, however if you hit a server that has not received this upgrade, the data is still very close to the exchange time-stamps. The difference is practically negligible.

All servers should be upgraded within the next month or two.