Quote from dcraig:
No I didn't. There are plenty of problems with this.
These things are no use for generating constant volume bars (for example). How do you know which bar the high and low belong to ?
If you consider the incoming data to be a stream, going back in time and patching values in the stream is just horrible. Suppose you want to compute a moving average of highs of an OHLC series. Like I said, it is a mess.
Are chart vendors going to support this ? I wouldn't blame them if they didn't. I find it hard to believe that any other feed works like this. It may just be too much trouble. Going back and repainting the previous bar might require significant changes to their charting code.
It has the flavour of a hack to get around problems with low bandwidth links but this is a solution looking for a problem that is rapidly disappearing. ADSL and cable are widely available and 10 - 20 Mbit/sec ADSL is becoming increasingly common. Futhermore, on the server side compute power is getting cheaper and cheaper. Intel just announced price cuts. By the end of the month you will be able to buy a quad core CPU for about $550. You can drive a lot of tick streams with just one of these.
IMHO, a simpler and better (though not perfect) solution would be to just up the maximum sample rate on the current feed. No client side software changes, and it would look more like a true tick feed. TWS on modern CPUs should easily handle a doubling of the data rate.
I think it is clear that you don't understand. You wrote, "How can a 5 second OHLC bar be "real time" ? What a mess." You thought that the 5 second bars were being presented as "real time", when in fact, the 5 second bars were presented
in addition to the existing real-time feed.
Your idea to increase the sampling rate of the real-time feed will not succeed in catching all highs and lows. It is a statistical property of market behavour that there will always be occasional bursts of rapid price changes which occur more rapidly than the data sampling rate, no matter how quickly that rate is chosen. So increasing the sampling rate won't solve the problem of his and los missing from a snapshot feed.
I don't think the design of the feed is a hack. I think it strikes a wise and clever balance between the competing design goals of data completeness and feed efficiency. It keeps the feed up to date, no matter how rapidly the market is ticking (provided nothing else goes wrong to interfere with the feed, and we have recently experienced some difficulties in these other areas, but IB says it is addressing those). I have seen many customers complain that other datafeeds, which transmit every single tick instead of snapshots, fall behind during the inevitable bursts of rapid price changes. The IB feed reflects the more important priority of knowing where the market is right now, instead of getting every single tick after it is already too late to use the information.
I think that the problems with generating constant volume charts are, and will continue to be, very minor or non-existent, unless you are making them on an extremely short time scale of seconds per bar. Quotetracker already generates constant volume bars from the IB feed, and I'm sure none of IB's changes will interfere with QT's ability to continue doing so.
I see no reason why chart vendors would not support the improvements to IB's feed. QT has made many changes to adapt to IB's past datafeed changes, and to take advantage of improvements such as the addition of backfill.
