NexusFi: Find Your Edge


Home Menu

 





Keep your pc clock synchronized


Discussion in Traders Hideout

Updated
      Top Posters
    1. looks_one gomi with 13 posts (30 thanks)
    2. looks_two cunparis with 7 posts (7 thanks)
    3. looks_3 aslan with 5 posts (2 thanks)
    4. looks_4 Big Mike with 5 posts (1 thanks)
      Best Posters
    1. looks_one sam028 with 6.3 thanks per post
    2. looks_two NickA with 3 thanks per post
    3. looks_3 gomi with 2.3 thanks per post
    4. looks_4 cunparis with 1 thanks per post
    1. trending_up 28,209 views
    2. thumb_up 64 thanks given
    3. group 14 followers
    1. forum 48 posts
    2. attach_file 7 attachments




 
Search this Thread

Keep your pc clock synchronized

  #31 (permalink)
 gomi 
Paris
Market Wizard
 
Experience: None
Platform: NinjaTrader
Posts: 1,270 since Oct 2009
Thanks Given: 282
Thanks Received: 4,505

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 :-)

Reply With Quote

Can you help answer these questions
from other members on NexusFi?
Deepmoney LLM
Elite Quantitative GenAI/LLM
NexusFi Journal Challenge - April 2024
Feedback and Announcements
NT7 Indicator Script Troubleshooting - Camarilla Pivots
NinjaTrader
Futures True Range Report
The Elite Circle
Exit Strategy
NinjaTrader
 

  #32 (permalink)
 
aslan's Avatar
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
Posts: 625 since Jan 2010
Thanks Given: 356
Thanks Received: 1,127

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).

Reply With Quote
Thanked by:
  #33 (permalink)
 
Big Mike's Avatar
 Big Mike 
Manta, Ecuador
Site Administrator
Developer
Swing Trader
 
Experience: Advanced
Platform: Custom solution
Broker: IBKR
Trading: Stocks & Futures
Frequency: Every few days
Duration: Weeks
Posts: 50,393 since Jun 2009
Thanks Given: 33,172
Thanks Received: 101,530



gomi View Post
Little upgrade on the topic. Here's how my clock is doing.

As you can see, for now the algo isn't making my offset converge.
Offset is the measure you're interested in, because it indicates the error between the local clock and the estimated global NTP time( time of servers with * or + on the NTP status)

What I know though is that my time is somewhere between +20/-20 ms of the estimated time. I want better !

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.

Mike

We're here to help: just ask the community or contact our Help Desk

Quick Links: Change your Username or Register as a Vendor
Searching for trading reviews? Review this list
Lifetime Elite Membership: Sign-up for only $149 USD
Exclusive money saving offers from our Site Sponsors: Browse Offers
Report problems with the site: Using the NexusFi changelog thread
Follow me on Twitter Visit my NexusFi Trade Journal Reply With Quote
  #34 (permalink)
 gomi 
Paris
Market Wizard
 
Experience: None
Platform: NinjaTrader
Posts: 1,270 since Oct 2009
Thanks Given: 282
Thanks Received: 4,505

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.



aslan View Post
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).


Reply With Quote
  #35 (permalink)
 gomi 
Paris
Market Wizard
 
Experience: None
Platform: NinjaTrader
Posts: 1,270 since Oct 2009
Thanks Given: 282
Thanks Received: 4,505


Big Mike View 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.

Absolutely, but in this specific case I was trying to get the best stable PC clock... For now it's far far far worse than D4 :-)

Reply With Quote
  #36 (permalink)
 
aslan's Avatar
 aslan 
Madison, WI
 
Experience: Advanced
Platform: ALT
Trading: ES
Posts: 625 since Jan 2010
Thanks Given: 356
Thanks Received: 1,127


gomi View Post
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!

Reply With Quote
Thanked by:
  #37 (permalink)
 NickA 
London
 
Experience: None
Platform: MC & Ninja mainly
Posts: 135 since Jan 2010
Thanks Given: 5
Thanks Received: 50

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.

Attached Thumbnails
Click image for larger version

Name:	zenapi.png
Views:	228
Size:	86.7 KB
ID:	13738  
Reply With Quote
Thanked by:
  #38 (permalink)
 
cunparis's Avatar
 cunparis 
Paris, France
 
Experience: Advanced
Platform: Market Delta & Ninjatrader
Trading: ES
Posts: 2,565 since Jun 2009
Thanks Given: 1,162
Thanks Received: 2,093


NickA View Post
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.

Can anyone use the API or do you have to pay a fee?

Follow me on Twitter Started this thread Reply With Quote
  #39 (permalink)
 syxforex 
British Columbia
 
Experience: Advanced
Platform: NINJA
Broker: ZEN
Trading: Crude
Posts: 1,091 since May 2010

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.

Visit my NexusFi Trade Journal Reply With Quote
  #40 (permalink)
 syxforex 
British Columbia
 
Experience: Advanced
Platform: NINJA
Broker: ZEN
Trading: Crude
Posts: 1,091 since May 2010


And now that I have read the thread it is clear I'm the only person in the sun-dial era....

Visit my NexusFi Trade Journal Reply With Quote





Last Updated on January 13, 2012


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts