Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
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...
Still investigating :-)
Can you help answer these questions from other members on NexusFi?
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).
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.
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.
Yes, I was not saying you were wrong to be trying, only trying to figure out why such precision is needed, and depending what you are trying to do, it still may not be good enough.
I would like to see more precision from the exchange/vendors, but not holding my breath. Tradestation still does not have seconds!
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.
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.