Ninja Zen no more unfiltered data?

Also, the clock skew / inaccurate timing issue discussed earlier should not matter. The timestamp should be taken from the data feed, not the time on the local PC.
 
Quote from SNYP40A1:

Wow, glad to see I'm not the only one building analysis tools on Java in Linux. I also have an in Memory DOM table, but I can't validate it because some trades are not making sense, I think due to the issue talked about on this forum, which is what caught my attention. You could create an abstraction layer for your feed, but I personally would not. Most of the APIs that I have seen are similar enough and all I am doing at that layer is writing a callback function that pulls out about 5 pieces of information for each Tick. I try to keep the tick receiving logic as simple as possible to ensure that it will always respond quickly during heavy activity. So far that's not been an issue although I have a dedicated computer for receiving the data feed.
More...

I have Level 1 abstraction layer that is fine for the three feeds I have supported so far - IB TWS, OpenTick (now defunct) and DTN IQFeed. Each tick results in a tick event (eg last, bid, last size etc etc). Tick listeners register themselves to receive tick events in the Java style of event listeners. Most stuff is decoupled from the tick data receive thread via tick event queues and quite extensive threading.

It is easily fast enough. Monitoring 500 stocks and some futures, and even with flashing "christmas tree" quote sheets, alarms, charting, 4 screens, modest video cards etc etc, a Q9550 is still loafing along. Even in a fast market it's still 70%+ idle. I'm certain that most of the CPU utilization is in the AWT event processing thread doing GUI things.

Java is the biz for this stuff. If I was using C++ it would have taken far longer.
 
Quote from SNYP40A1:

Also, the clock skew / inaccurate timing issue discussed earlier should not matter. The timestamp should be taken from the data feed, not the time on the local PC.
More...

If it has one. IB TWS doesn't.
 
Bid and Ask Offers are constantly changing and the exchange only time stamps the last trade which could be seconds past the instant real time or even minutes for thinner traded instruments ie M6E.

The clock skew is just one part of the equation. Add in network latency and CPU time to process and filter the price feed. Time required to process orders and confirm fills + error checking etc.

My point was accurately processing feeds, placing and managing orders sub 50ms is a challenge.


Quote from SNYP40A1:

Also, the clock skew / inaccurate timing issue discussed earlier should not matter. The timestamp should be taken from the data feed, not the time on the local PC.
More...
 
Quote from PocketChange:

Bid and Ask Offers are constantly changing and the exchange only time stamps the last trade which could be seconds past the instant real time or even minutes for thinner traded instruments ie M6E.

The clock skew is just one part of the equation. Add in network latency and CPU time to process and filter the price feed. Time required to process orders and confirm fills + error checking etc.

My point was accurately processing feeds, placing and managing orders sub 50ms is a challenge.
More...

For the purpose of this thread, the issue is whether last trade was executed at bid or ask. I can't see what clock skew, network latency or managing orders on a 50ms time frame has got to do with it.
 
We have no favorite data provider and primarily rely on our broker supplied feeds: TT and OEC. We have used e-signal and others as independent control feeds but found our two primary broker feeds to be sufficient for our purposes.

However, we are not focused on collecting and logging pricing data. Our focus is on real time order processing and position management. The pricing data we do collect is what we consider "executable" within the realm of our order process and capacity of our systems.

One tool we have found particularly useful is OEC's Market Replay plug-in. Does a nice job of recording Level I quotes, Level II DOM, histograms etc. provides a decent environment to test out your trading algo's.


Quote from maxima120:

Sooo... PC.. Reveal the secret - who is the favourite data provider of yours? ;)
More...
 
Quote from PocketChange:
One tool we have found particularly useful is OEC's Market Replay plug-in. Does a nice job of recording Level I quotes, Level II DOM, histograms etc. provides a decent environment to test out your trading algo's. [/B]
More...
Thats interesting.. Does OEC have subsecond timestamp within the plug-in ? How accurate it is? 50ms?
 
For purposes of collecting and logging pricing data it makes no difference other than the accuracy of a time stamp.

Quote from dcraig:

For the purpose of this thread, the issue is whether last trade was executed at bid or ask. I can't see what clock skew, network latency or managing orders on a 50ms time frame has got to do with it.
More...
 
The exchange time stamps are in full seconds.
Replay speed is adjustable from 1/10 to 100x.
Not sure what their data sample rate are... guessing 100ms.

Quote from maxima120:

Thats interesting.. Does OEC have subsecond timestamp within the plug-in ? How accurate it is? 50ms?
More...
 
You must log in or register to reply here.
Back
Top