IB - data generation process

Discussion in 'Data Sets and Feeds' started by kiwi_trader, Jul 21, 2006.

  1. kostia00,

    I think that these changes are very good. But why not also include, in each real-time snapshot, the highest and lowest prices which have occured since the fraction of a second of time since the previous snapshot? This way, charts would immediately reflect high and low values, without any 5 second delay. Charts already reflect the most recent prices, at the time of each snapshot, without any delay, and with a few snapshots happening each second; but the highest and lowest values occurring in between these snapshots will be delayed up to 5 seconds in the current plan.

    By the way, I don't want newbie traders to be misled by my suggestion. The IB data feed is already superb, aside from occasional breakdowns and problems which IB is addressing through various planned improvements. The changes just announced by kostia00, to the design of the datafeed, are going to make it better by tweaking it slightly, even though it was already superb. I am suggesting yet another way to tweak it even a little better. Many newbie traders misinterpret these types of debates to indicate that IB data are somehow inferior or slow. Nothing could be further from the truth, in my opinion, and I know very many traders agree with me on this.
    #31     Mar 28, 2007
  2. kostia00

    kostia00 Interactive Brokers

    Hi Jim!

    I believe our main consideration is the network bandwidth usage. We would like to make sure we can keep up with the demand for this data before we commit to providing any higher-frequency high/low data. Thanks!
    #32     Mar 28, 2007
  3. If the issue is network bandwidth usage, why not JUST get more bandwidth??????
    #33     Mar 28, 2007
  4. rwk


    It's customer bandwidth as well as IB's bandwidth.
    #34     Mar 28, 2007
  5. would IB ever consider offering a 'level 2' data connection which could be paid for. on its own fiber. where users who want/need every tick realtime as if we were directly connected to the exchanges? and are willing to pay for the improvement?

    maybe also dealing with the msgs / second limit. im surprised that IB would limit an API using client to 50 (or 150) messages. Id imagine any money saved in bandwidth costs (if that is the reason for limiting messages) wouldn't offset the lost commissions from rejected / delayed orders. a few extra bytes of bandwidth for a possible 2.50+ commission seems like a good deal.
    #35     Mar 28, 2007
  6. He said nothing about customer bandwidth.

    He stated it's about THEM keeping up with bandwidth. I have a 19.2mb/s (1.9 MB/s) down pipe, so customer badnwidth for this little packet data shouldnt be an issue.

    I have a DTN.IQ feed and at most have 13-15 T&S windows open. (average 6-8) Never had a bandwidth issue there.

    SO I am gonna lean on HIS words. So again I ask, if it is a bandwidth issue, why not get more bandwidth????

    BTW, Personally it isnt an issue with me, My DTN data feed is my mainstay. As horrible as the TWS charts are...(IMO)

    My question is one of understanding the mindset of with whom I am in business with.
    #36     Mar 28, 2007
  7. kostia00

    kostia00 Interactive Brokers

    It is both internal network bandwidth required to deliver data from N exchanges to M distribution servers, and external network bandwidth to deliver from M distribution servers to customers.

    The question of whether to get more of either or both is more than a technical question and will be examined by IB management: note that as we are not charging for the backfill and for 5-second bars (besides regular market data fees), we would like to keep the costs of these additional services under control.
    #37     Mar 28, 2007
  8. Sounds fair to me... :)
    #38     Mar 28, 2007
  9. It depends on what instruments you trade. For "thick" futures like ES or ZN, it will be less of an issue than with YM, ZG or ER2.
    #39     Mar 28, 2007

  10. excellent!:)
    #40     Mar 28, 2007