Понимание событий тиков Interactive Brokers

При получении финансовых тиковых данных с помощью методов API Interactive Brokers tickPrice или tickSize данные будут иметь следующие параметры

  • тиккерид (символ)
  • поле (1=ставка, 2=аск, 4=последний, 6=высокий, 7=низкий, 9=закрытый)
  • цена
  • canAutoExecute

От любого другого канала я бы ожидал, что мне поставят галочку

  • тиккерид (символ)
  • делать ставку
  • просить
  • размер ставки
  • спросите размер

Итак, мой вопрос: должен ли я хранить словарь с tickerId в качестве ключа и структуру в качестве значения, содержащего пять вышеуказанных свойств, чтобы каждый раз, когда возникает событие тика, я обновлял бы соответствующее свойство структуры и отправлял всю структуру в мою базу данных как клещ? В идеале моя база данных тиков выглядела бы примерно так

Date        Time            Symbol  Side    Price   Quantity
2012-10-31  13:51:13.784    AAPL    Bid     25.81   15007
2012-10-31  13:51:14.615    AAPL    Bid     25.82   10
2012-10-31  13:51:14.633    AAPL    Bid     25.81   13623
2012-10-31  13:51:14.684    AAPL    Ask     25.82   2500
2012-10-31  13:52:09.168    AAPL    Bid     25.80   12223

Из документации IB API: Этот метод вызывается при изменении рыночных данных. Означает ли это, что если, например. цена предложения обновляется, остальные свойства останутся прежними?


finance algorithmic-trading interactive-brokers
person Morten    schedule 04.09.2014    source источник
comment
мудрый вопрос, но есть кое-что, что мне до сих пор не ясно. Как правильно определить дату и время этого конкретного тика? Не похоже, что tickPrice или tickSize возвращают информацию с отметкой времени.   -  person simonemainardi    schedule 03.04.2016
comment
IB не отправляет временные метки - вы должны использовать текущее системное время на каждом тике. Как уже упоминалось в ответах ниже, данные представляют собой не настоящие тики, а снимки за 200-300 мс.   -  person Morten    schedule 03.04.2016
comment
для меня текущее системное время почти бесполезно. Он может иметь произвольную неизвестную непредсказуемую задержку относительно реального времени тика. Рассогласование системных часов, дрожание сети, повторные передачи пакетов и т. д. Я не уверен, как вы можете надежно использовать текущее системное время.   -  person simonemainardi    schedule 03.04.2016
comment
IB никогда не был и, вероятно, никогда не будет точным и надежным источником потоковых рыночных данных в реальном времени. Это бесплатно.   -  person Fred Quatro    schedule 15.03.2017
comment
@FredQuatro Обратный вызов tickPrice действительно бесполезен без меток времени. В последнем API есть tickByTickAllLast и tickByTickBidAsk с отметками времени.   -  person Navin    schedule 09.04.2020

Ответы (3)


arrow_upward
6
arrow_downward

Ты прав. Всякий раз, когда изменяется определенное свойство, будет инициировано новое событие тика. Ваш дизайн использования структуры для сохранения моментального снимка тика является одним из стандартных подходов.

Другими словами, API IB будет отправлять каждый агрегированный тик по мере его поступления. Однако эти тики не являются настоящими тиками, так как они представляют собой моментальные снимки всего 0,2–0,3 секунды. Если вы имеете дело с HFT, то эти данные бота могут быть надежными для моделирования стакана заказов. Однако, если вы просто выполняете базовый анализ данных, то их качество приемлемо.

Их максимум, минимум и цена закрытия в этом случае могут быть бесполезны, так как стандартный стакан не будет содержать информацию о максимуме, минимуме и закрытии. Обычно я их выбрасываю. Размер бида и аска в этом случае также ненадежны, так как это всего лишь синтетические тики.

Надеюсь, мой ответ поможет.

person Simon    schedule 09.09.2014
comment
Большое спасибо. Я согласен, что IB не подходит для производственной ленты. - person Morten; 10.09.2014
comment
@Morten, я думаю, это сильно зависит от стратегии. Для чего-то, работающего с почасовыми/ежедневными и, честно говоря, даже минутными данными, это действительно нормально. Я думаю, что многим людям нужны правдивые рыночные данные, пока у них не появится много символов для отслеживания и не наступит тяжелый день. Даже с приличным оборудованием и отличными сетевыми соединениями вы можете увязнуть, поскольку API IB, поскольку это моментальный снимок, не будет страдать от этих проблем. - person Eric; 17.12.2015

arrow_upward
5
arrow_downward

Это зависит от того, что вы вводите в метод reqMktData():

void reqMktData(       TickerId          id,
                 const Contract         &contract,
                       IBString         &genericTicks,
                       bool              snapshot,
                 const TagValueListSPtr &mktDataOptions
                       )

Если вы напишете snapshot = true, вы будете получать снимки данных каждые ~0,2–0,5 секунды. Если бид или цена изменились, вы это увидите.

Если вы напишете snapshot = false, вы будете получать новую переменную ставку или запрос при каждом ее изменении.

person ibapilessons    schedule 23.10.2016
comment
Хорошая статья, @ibapilessons. Не могли бы вы также добавить некоторые идеи о том, как добавить временные метки на стороне поставщика данных (без джиттера)? - person user3666197; 23.10.2016
comment
@ibapilessons - Вы уверены в этом? С веб-сайта IB (interactivebrokers.com/en/software/api/ apiguide/c/), вы можете видеть, что там написано: Отметьте, чтобы вернуть один снимок рыночных данных и отменить подписку на рыночные данные. Не вводите какие-либо значения genericTicklist, если вы используете моментальный снимок. И согласно моему тестированию, установка моментального снимка на true вернет данные моментального снимка и отменит текущую подписку на данные. - person Yaniv; 08.01.2017
comment
Я уверен в этом. Но в любом случае, если у вас возникла подобная проблема, звоните в Interactive Brokers. - person ibapilessons; 09.01.2017

arrow_upward
3
arrow_downward

Когда вы рассматриваете поток данных, который предоставляет IB, рассмотрите ситуацию, когда вы хотите обновить данные в форме/странице отображения. В этом случае, если биржа сгенерирует новую лучшую котировку бида по той же цене бида, только с другим размером, то имеет смысл отправлять только новый размер (а не цену бида снова, которая не изменилась). Кроме того, IB будет группировать эти изменения в течение примерно 200 или 300 миллисекунд, поэтому не каждое изменение распространяется.

Если вы посмотрите на это в этом контексте, поток данных на самом деле довольно эффективен с точки зрения минимизации размера и частоты сообщений.

Вместо этого большинство людей знакомы с тем, что предоставляет более полный поток данных уровня 1 (например, Consolidated Quote System). В этом случае каждое изменение цены или размера генерирует новое сообщение с котировкой, содержащее все поля.

Какой тип потока данных вам требуется, во многом зависит от вашего конкретного варианта использования. Например, я работал над предоставлением клиентам очень подробных (т.

Таким образом, это действительно вопрос способности сопоставить ваши требования к данным с вашими требованиями к анализу. В некоторых случаях данные IB будут работать нормально. В остальных случаях не будет.

person user3276159    schedule 23.03.2016