Yep, for sure... +20/-20 is nothing to be excited about ... If you have 2 ms accuracy in measuring the latency between you and the time server, and the time server has 2 ms accuracy , a basic NTP V3 client will give you 4 ms accuracy...
This may be getting off topic, and perhaps it needs it own thread, but why do you need such an accurate timestamp?
I know you are trying to timestamp ticks better, but in reality what matters is the order of the bid/ask and ticks.
The problem with sec timestamps, is you might get 1000 ticks in a 1 sec interval (not to mention bid/ask updates), and how do you order those if they all have the same timestamp? Well everyone wants ms timestamps. Well that is all and good, but what if you now have 300 of those original ticks within 1 ms? You are still stuck. Again, you have to deal with the order of the events, and the only way to do that reliably is to use an event counter in addition to the timestamp. The problem here is that is yet another field that needs to be stored with your ticks and parsed when you read the ticks back, and developers don't want to pay the cost or deal with it. Dealing with relative order between instruments within a sec interval is another layer.
If you look at the IQFeed, they have solved this in two ways. First, when they send historical tick data, they send the bid/ask/last as a single unit, so you don't have to parse the bid/ask to figure out if the trade was a buy/sell. Secondly, when sending live data each tick has an ID. Now you pay a price for this processing, as the IQFeed is slightly slower (I suspect due to the additional processing).
So at the end of the day, more timestamp resolution may not be the solution (though I would like to see ms resolution).
The following user says Thank You to aslan for this post:
Gomi, I am thinking that you are not so much dealing with a variation of your PC time vs. Exchange time, but instead dealing with the 'bursts' of data that are lagging more then less then more again from your data provider. The Exchange time, and your PC time, are most likely relatively fixed over a short window of minutes to hours, but the data feed itself is not fixed.
Due to time constraints, please do not PM me if your question can be resolved or answered on the forum.
Need help? 1) Stop changing things. No new indicators, charts, or methods. Be consistent with what is in front of you first. 2) Start a journal and post to it daily with the trades you made to show your strengths and weaknesses. 3) Set goals for yourself to reach daily. Make them about how you trade, not how much money you make. 4) Accept responsibility for your actions. Stop looking elsewhere to explain away poor performance. 5) Where to start as a trader? Watch this webinar and read this thread for hundreds of questions and answers. 6) Help using the forum? Watch this video to learn general tips on using the site.
If you want to support our community, become an Elite Member.
Well, this can be turned the other way round.. Who needs second resolution ? Aren't minute charts sufficent ;-) ?
Suppose I want to develop a time profile indicator, to spot areas where market tested the water a very short time and reversed. And by very short I mean less than a second. With a second resolution datafeed I can't do it.
I probably don't need millisec, maybe decisec or centisec could be enough, but either way 1 second is too slow.
Gomi, slightly off topic but the Zenfire API returns millisecond time stamped events. I guess NT just ignores this info as it stores stuff to 1 second resolution. I am not sure but I believe the data is time stamped by the Zen ticker plant.
The Zenfire API looks pretty straight forward and there is a sample app for download that compiles and gets ticks into a grid (full order book). I am not sure what your objective is but it might be worth considering recording straight from the API if you want millisecond accuracy (assuming that the data is time stamped at the exchange end). I hear that it is reasonably straight forward to pass the data on to NT though would not know myself. I guess you could save it straight into a Gomi recorder file.
The following 3 users say Thank You to NickA for this post:
About a year ago I took a demo of CQG. Their technical people are very impressive. I was on Vista at that time and it was crashing. They suggested it was likely because their servers use atomic precision in keeping time and that the issues were clock related.