QuickFIX/J FIX Engine

[byteme]

Quote from chaffcombe:

BGH

I would agree that when you develop a standard for server to server communications, one would expect a time synchronisation function. Nonetheless, I'm curious as to why this is so critical to you.

In a typical FIX trading scenario we receive a constant stream of ticks with no artifical time horizons, to which we react, one way or another.

To me, time is no more than a convenient measure used for organisation and sequencing. I cannot think why it would be essential to be in perfect agreement.

I'm happy to be enlightened, however! ;-)

Many people do not use FIX for market data, only for execution. Standard FIX isn't particularly efficient for high-frequency data, hence the invention of FAST.

I suspect the time synchronization issues that the other poster is having may be related to the execution part of the equation i.e. when receiving execution reports etc.???

Due to the fact that Interactive Brokers is the broker in question, all bets are off though!

 

[dcraig]

Quote from Big Game Hunter:

I mean Ive been over this one before. I dont see why when your implementing a standard for communicating between 2 computers ( a server and a host) that you dont provide a way of synching the 2 clocks together. It just doesnt make sense any other way. I mean even slight differences in the way that each computer interprets the current time can have unforseen negative effects.

You could suggest to your broker that they create a publicly available NTP server synced to their network's idea of the time, and use NTP for time sync with your machine(s). Much better than cobbling together something in the application protocol.

http://www.faqs.org/rfcs/rfc1305.html

However, I would have thought that if you keep your machines in sync with just about any publicly available NTP server, that should be good enough. I would suggest that without special hardware, you could always be "off" by the order of milliseconds (maybe 10-100 msecs), no matter what you do.

 

[Big Game Hunter]

The reason that I consider it so critical is because it can lead to mistakes being made in creating bars. For example if Im drawing 1 minute bars and my ATS thinks its 59 seconds and the trading server is a full second ahead and is already drawing the next bar (ie1:00) then the quotes that should be on the next bar are instead on the prior bar. That in turn means that the orders that are generated by the ATS are conceivably incorrect because theres quotes that should be on the next bar that are instead included on the prior bar. And that means that now your bars and the bars of your broker no longer match.

 

[byteme]

Quote from Big Game Hunter:

The reason that I consider it so critical is because it can lead to mistakes being made in creating bars. For example if Im drawing 1 minute bars and my ATS thinks its 59 seconds and the trading server is a full second ahead and is already drawing the next bar (ie1:00) then the quotes that should be on the next bar are instead on the prior bar. That in turn means that the orders that are generated by the ATS are conceivably incorrect because theres quotes that should be on the next bar that are instead included on the prior bar. And that means that now your bars and the bars of your broker no longer match.

Are you using FIX for data feed?

Many data feeds timestamp their data so if you build bars from the embedded timestamp you'll be in sync with the producer of the timestamp - at least as far as bars are concerned.

Examine the messages coming to see if there are timestamps in the market data.

 

[chaffcombe]

Yes, and along the same lines - many trade platforms do not provide bar data - just ticks - which means that if your analysis depends on say 5 min bars, you have to construct them yourselves.

It should be noted that while most of us use bars for trade decison purposes, they are a completely artifical construct. A market makers bars are no more valid than ones you can produce yourself via the underlying tick data, even if your clocks are slightly different.

All I'm really saying is don't get too hung-up on this one.

~chaffcombe

 

[Cybren]

Quote from chaffcombe:

Yes, and along the same lines - many trade platforms do not provide bar data - just ticks - which means that if your analysis depends on say 5 min bars, you have to construct them yourselves.

It should be noted that while most of us use bars for trade decison purposes, they are a completely artifical construct. A market makers bars are no more valid than ones you can produce yourself via the underlying tick data, even if your clocks are slightly different.

All I'm really saying is don't get too hung-up on this one.

~chaffcombe

Couldn't agree more, the whole bar concept is just a construct to begin with. But aside form this, FIX gives you a timestamp on market data which you can even offset if you want to to have your calculated bars start and stop anyway you possibly like. In reality you have other more important things to worry about if you want to use bars that you construct to base trading decisions on. For example think about how you can filter out bad ticks that mess up trading decisions.

Not saying that you have no point, but just focus on more important things as this one is very very very minor.

Good luck developing all.

Sybren