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.
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.
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.
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.
For purposes of collecting and logging pricing data it makes no difference other than the accuracy of a time stamp.
PC, have you encountered any volume or data problems since November 2009 with OEC data like those mentioned in this thread........ http://www.traderslaboratory.com/forums/f218/oec-histogram-faulty-volume-7105.html TIA!
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.