|
Автор |
|
|
API и DDE
Добрый день,Уважаемые разработчики! Прошу объяснить: Есть два способа получения информации о сделках и заявках Первый способ - экспорт таблиц сделок и заявок по DDE Второй способ - получение по подписке через API Интересуют следующие моменты: 1)Какой из способов быстрее. 2) Использование подписки через API - это самостоятельные запросы к серверу или обращение к внутренним данным QUIK 3) Терминал QUIK обслуживает API и DDE в одном потоке или в разных. Спасибо
|
|
nikolz
11/02/12 12:07
|
|
|
|
|
Здравствуйте, 1) Мы не проводили исследований по скорости обработки этих способов. Будем признательны, если Вы самостоятельно проведете эксперимент и отпишитесь в этой ветке форума. 2) Api работает с терминалом Quik,
»»»
Здравствуйте, 1) Мы не проводили исследований по скорости обработки этих способов. Будем признательны, если Вы самостоятельно проведете эксперимент и отпишитесь в этой ветке форума. 2) Api работает с терминалом Quik, а терминал уже с сервером 3) Это разные потоки.
|
|
Горохов Сергей, ARQA Technologies
13/02/12 09:09
|
|
|
|
|
Всем добрый день! Отвечаю на первый вопрос: Что передает информацию раньше API или DDE. DDE передает информацию раньше,чем API. Уважаемые разработчики! Прошу высказать свои предположения относительно следующего факта. При передачи
»»»
Всем добрый день! Отвечаю на первый вопрос: Что передает информацию раньше API или DDE. DDE передает информацию раньше,чем API. Уважаемые разработчики! Прошу высказать свои предположения относительно следующего факта. При передачи данных стакана по DDE получаю для стакана с РТС (фьючерс сбербанка) 80-90 mc для стакана с ММВБ(акция сбербанка) 800-900 mc. Непонятна причина большой задержки по стакану с ММВБ. Спасибо
|
|
nikolz
20/02/12 11:10
|
|
|
|
|
Уважаемые разработчики! Судя по временным диаграммам , передача ТТП происходит при изменении одной строки в таблице. В результате получаем большой поток мелких пакетов. Но информацию об изменении ТТП терминал QUIK
»»»
Уважаемые разработчики! Судя по временным диаграммам , передача ТТП происходит при изменении одной строки в таблице. В результате получаем большой поток мелких пакетов. Но информацию об изменении ТТП терминал QUIK получает по группе строк. Предлагаю, с целью снижения загрузки процессора, передавать по DDE один пакет изменения ТТП, соответствующий принятому пакету терминала QUIK от сервера, а не разбивать его то строкам таблицы. Спасибо.
|
|
nikolz
20/02/12 11:39
|
|
|
|
|
Здравствуйте, Если экспорт производился с одними и те ми же настройками, то можно судить, что к Вам данные от ММВБ поступают медленнее чем от РТС. Дело в том, что эти
»»»
Здравствуйте, Если экспорт производился с одними и те ми же настройками, то можно судить, что к Вам данные от ММВБ поступают медленнее чем от РТС. Дело в том, что эти данные идут от разных шлюзов, по тому и различия.
|
|
Горохов Сергей, ARQA Technologies
20/02/12 12:08
|
|
|
|
|
Добрый день,Горохов Сергей! Благодарю за ответ. 1) А вот как можно объяснить следующие различия: Задержка стакана по фьючерсу 80 ms а задержка стакана по RTS-standard - 125 ms 2) Читал,
»»»
Добрый день,Горохов Сергей! Благодарю за ответ. 1) А вот как можно объяснить следующие различия: Задержка стакана по фьючерсу 80 ms а задержка стакана по RTS-standard - 125 ms 2) Читал, что интервал передачи информации по шлюзу ММВБ 250 ms, а я наблюдаю 800-1000 ms,чем это можно объяснить? Спасибо
|
|
nikolz
20/02/12 12:14
|
|
|
|
|
Re: API и DDE
Интересует момент, как Вы замеряете скорость? Дело в том, что потоки данных не всегда статичны в определенный момент времени. Однозначно судить о скорости можно только проведя серию продолжительных тестов.
|
|
Горохов Сергей, ARQA Technologies
20/02/12 12:23
|
|
|
|
|
Горохов Сергей! Время измерятся как интервал между приходом пакетов по DDE Например для стакана Вы всегда передаете всю таблицу, поэтому при включении трансляции одного стакана время между пакетами будет равно
»»»
Горохов Сергей! Время измерятся как интервал между приходом пакетов по DDE Например для стакана Вы всегда передаете всю таблицу, поэтому при включении трансляции одного стакана время между пакетами будет равно интервалу обновления информации или периоду поступления данных с сервера. При это задержка по каналам не влияет, так как ее величина на интервале измерения практически постоянная. Есть проблемы измерения при приеме многих таблиц. Но эту проблему я исключаю трансляцией одной таблицы. Например, сейчас интервал обновления стакана любого составляет 1000 ms, т е 1 секунду ровно. 100 замеров и всегда ровно 1000 ms Вопрос, кто в данном случае установил такой интервал? У меня в КВИКЕ Интервал обновления данных с текущим состоянием не установлен. Может где-то в файлах настройки задано 1 секунда? Или это брокер установил задержку? Или это биржа? Прошу объяснить Спасибо
|
|
nikolz
20/02/12 14:15
|
|
|
|
|
Здравствуйте, Интервал в 1 секунду является параметром DDE по умолчанию. Его также можно задать вручную, внеся изменения в файл info.ini.Откройте файл и найдите секцию [excel]. Если этой секции нет —
»»»
Здравствуйте, Интервал в 1 секунду является параметром DDE по умолчанию. Его также можно задать вручную, внеся изменения в файл info.ini.Откройте файл и найдите секцию [excel]. Если этой секции нет — внесите её, скопировав из сообщения: [excel] price-timeout=90 Минимальное значение — 10. Параметр измеряется в миллисекундах.
|
|
Горохов Сергей, ARQA Technologies
20/02/12 14:37
|
|
|
|
|
Re: API и DDE
спасибо.
|
|
nikolz
20/02/12 14:53
|
|
|
|
|
Горохов Сергей! Действительно,установив время 10 ms, я получил разброс интервала передачи стакана от 15 до 1000 ms. Прошу объяснить, каким образом, время между двумя пакетами стакана по DDE может составлять
»»»
Горохов Сергей! Действительно,установив время 10 ms, я получил разброс интервала передачи стакана от 15 до 1000 ms. Прошу объяснить, каким образом, время между двумя пакетами стакана по DDE может составлять 15 ms, если пинг до сервера брокера не менее 40 ms, а среднее время задержки обмена с сервером брокера не менее 100 ms Спасибо
|
|
nikolz
20/02/12 15:06
|
|
|
|
|
Здравствуйте. Описанную Вами картину можно объяснить возникновением очереди экспорта по DDE на участке "Клиентское место Quik - сервер DDE". Раундтрип 40 мс вовсе не означает, что задержка любых данных будет
»»»
Здравствуйте. Описанную Вами картину можно объяснить возникновением очереди экспорта по DDE на участке "Клиентское место Quik - сервер DDE". Раундтрип 40 мс вовсе не означает, что задержка любых данных будет составлять 40 мс. Это время в обе стороны и это время для одного пакета. Если речь идет о серии пакетов, то первый поступит через 40/2 мс после отправки, остальные из серии - непрерывно (пренебрегая временем обработки вне канала передачи). Увеличение времени обновления стакана до 1000 мс может объясняться: активностью на рынке, при которой в течениее 1000 мс стакан не изменялся; инфраструктурными особенностями участка сервер Quik - клиентское место Quik (ухудшение пропускной способности кнала связи, перегрузка системных ресурсов машины (настолько, что ОС не успевает вычитывать информацию по сетевому интерфейсу), задержки в вычитывании очереди DDE сервером); инфраструктурными особенностями участка сервер Quik - биржа. К сожалению, на потоке стаканов биржа не транслирует временнЫе метки, поэтому диагностика узких мест возможна только по косвенным признакам. Если Вы уточните задачу, то, возможно, мы предложим варианты решения.
|
|
Олег Хуснутдинов, ARQA Technologies
20/02/12 17:06
|
|
|
|
|
Добавим, что price-timeout=10 это довольно маленькое значение (высокая частота обновления), что повышает вероятность наличия очереди именно на участке вывода по DDE. Т.е. стакан выводится не по событию обновления стакана с
»»»
Добавим, что price-timeout=10 это довольно маленькое значение (высокая частота обновления), что повышает вероятность наличия очереди именно на участке вывода по DDE. Т.е. стакан выводится не по событию обновления стакана с сервера, а каждые price-timeout, и, если приложение DDE сервера не будет успевать вычитывать эту очередь, то Ваше внешнее приложение не будет получать актуальные данные.
|
|
Олег Хуснутдинов, ARQA Technologies
20/02/12 17:16
|
|
|
|
|
Добрый день,Олег Хуснутдинов! Благодарю за ответ. Давайте попробуем разобраться. Задача в создании платформы для разработки роботов в том числе и HFT. Попробую разгрести кучу причин,которую Вы указали. 1) Прием данных
»»»
Добрый день,Олег Хуснутдинов! Благодарю за ответ. Давайте попробуем разобраться. Задача в создании платформы для разработки роботов в том числе и HFT. Попробую разгрести кучу причин,которую Вы указали. 1) Прием данных из КВИКА осуществляется так быстро, что очередь из-за занятости канала быть не может. Вот результаты тестирования: Время приема любого пакета от КВИКА менее 1 ms. Точнее измерю позже. Так тестирование передачи данных из ТВС в 1 млн.записей показал следующее: Сначала КВИК готовит данные на это у него уходит 6 секунд Потом моя СУБД принимает записи и сортирует их по инструментам. На это уходит 2 секунды при 1000 инструментах. 2) Появление интервалов в 15 ms и 1300 ms происходит примерно с одинаковой частотой и не связано с загрузкой интернет канала (оптический канал 8 Мбит/c), не связано с движением рынка, не зависит от загрузки процессора (не более 30%) и происходит регулярно примерно 1 раз на 15 стаканов. Для наглядности Вот часть протокола параметр lt - интервал в ms Протокол: [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=219; lts=3616.31; Mon Feb 20 17:48:51 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=437; lts=3616.75; Mon Feb 20 17:48:52 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=656; lts=3617.4; Mon Feb 20 17:48:52 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=32; lts=3617.43; Mon Feb 20 17:48:52 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=187; lts=3617.62; Mon Feb 20 17:48:53 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=328; lts=3617.95; Mon Feb 20 17:48:53 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=875; lts=3618.82; Mon Feb 20 17:48:54 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=219; lts=3619.04; Mon Feb 20 17:48:54 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=125; lts=3619.17; Mon Feb 20 17:48:54 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=203; lts=3619.37; Mon Feb 20 17:48:54 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=219; lts=3619.59; Mon Feb 20 17:48:55 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=219; lts=3619.81; Mon Feb 20 17:48:55 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=15; lts=3619.82; Mon Feb 20 17:48:55 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=203; lts=3620.03; Mon Feb 20 17:48:55 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=438; lts=3620.46; Mon Feb 20 17:48:56 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=219; lts=3620.68; Mon Feb 20 17:48:56 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=437; lts=3621.12; Mon Feb 20 17:48:56 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=141; lts=3621.26; Mon Feb 20 17:48:56 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=62; lts=3621.32; Mon Feb 20 17:48:56 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=125; lts=3621.45; Mon Feb 20 17:48:57 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=1094; lts=3622.54; Mon Feb 20 17:48:58 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=125; lts=3622.67; Mon Feb 20 17:48:58 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=641; lts=3623.31; Mon Feb 20 17:48:58 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=218; lts=3623.53; Mon Feb 20 17:48:59 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=219; lts=3623.75; Mon Feb 20 17:48:59 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=344; lts=3624.09; Mon Feb 20 17:48:59 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=203; lts=3624.29; Mon Feb 20 17:48:59 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=656; lts=3624.95; Mon Feb 20 17:49:00 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=500; lts=3625.45; Mon Feb 20 17:49:01 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=344; lts=3625.79; Mon Feb 20 17:49:01 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=250; lts=3626.04; Mon Feb 20 17:49:01 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=656; lts=3626.7; Mon Feb 20 17:49:02 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=438; lts=3627.14; Mon Feb 20 17:49:02 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=1094; lts=3628.23; Mon Feb 20 17:49:03 2012 [4]0=R1C1:R41C3; Name=SPBFUT_SBRF; R=41; C=3: lt=31; lts=3628.26; Mon Feb 20 17:49:03 2012 Буду признателен, объясните данное явление Спасибо
|
|
nikolz
20/02/12 17:53
|
|
|
|
|
Уточните, пожалуйста, Ваш e-mail (или пришлите нам письмо на support@quik.ru) и мы выдадим инструкции по дополнительному логированию, т.к. только по Вашему логу картину составить будет затруднительно. Также просьба обратить внимание
»»»
Уточните, пожалуйста, Ваш e-mail (или пришлите нам письмо на support@quik.ru) и мы выдадим инструкции по дополнительному логированию, т.к. только по Вашему логу картину составить будет затруднительно. Также просьба обратить внимание на очереди диска на машине с клиентским местом Quik (в каких переделах находится параметр Физический диск(_Total)\Средняя длина очереди диска) во время экспорта.
|
|
Олег Хуснутдинов, ARQA Technologies
20/02/12 18:21
|
|
|
|
|
Re: API и DDE
Выслал письмо.
|
|
nikolz
20/02/12 18:41
|
|
|
|
|
Всем добрый день! Сегодня наблюдал период обновления стакана по DDE более 3 секунд, а так от 0.5 до 1 секунды практически постоянно. Это при пинге до сервера брокера за 0.03
»»»
Всем добрый день! Сегодня наблюдал период обновления стакана по DDE более 3 секунд, а так от 0.5 до 1 секунды практически постоянно. Это при пинге до сервера брокера за 0.03 секунды, обработки колбека по DDE за 0.003 секунды и средней задержки обмена сервера с терминалом КВИК по информационному окну в 0.14 секунды. Брокер Открытие. Может в консерватории надо что-то исправить?
|
|
nikolz
22/02/12 11:10
|
|
|
|
|
Re: API и DDE
пардон, ошибся время обработки по DDE 0.0003 сек.
|
|
nikolz
22/02/12 11:14
|
|
|
|
|
Уважаемые разработчики! Прошу объяснить, каким образом при обработке Вашим сервером транзакции за 2 ms (это Вы хвалились на Вашем десятилетии) Я получаю обновление таблицы заявок(стакана) с периодом от 1000 до
»»»
Уважаемые разработчики! Прошу объяснить, каким образом при обработке Вашим сервером транзакции за 2 ms (это Вы хвалились на Вашем десятилетии) Я получаю обновление таблицы заявок(стакана) с периодом от 1000 до 3000 ms. Или так специально делается, что бы заставить покупать места в дата центрах брокеров?
|
|
nikolz
22/02/12 11:53
|
|
|
|
|
Вопрос звучит примерно так: "почему самолет летит 5 часов, а бананы в магазин завозят раз в неделю?" Пр чем тут самолет? ну, сказать по-правде, в вашем вопросе тоже не понятно
»»»
Вопрос звучит примерно так: "почему самолет летит 5 часов, а бананы в магазин завозят раз в неделю?" Пр чем тут самолет? ну, сказать по-правде, в вашем вопросе тоже не понятно почему вы сравниваете время обработки (уже пришедшей не него) транзакции сервером с периодом обновления стакана на клиентском терминале (вернее даже с периодом обновления по внешнему интерфейсу)? как эти времена вообще связаны на ваш взгляд? (раз вопрос так ставите - связаны, очевидно?)
|
|
i-trade
22/02/12 21:01
|
|
|
|
|
Кажется до Николая начинает постепенно приходить понимание, что без нормального АПИ робота не сделать. И Квик - это только для поиграться. Годы, потраченные на изучение Купайла, вот-вот вылетят в трубу
»»»
Кажется до Николая начинает постепенно приходить понимание, что без нормального АПИ робота не сделать. И Квик - это только для поиграться. Годы, потраченные на изучение Купайла, вот-вот вылетят в трубу :-)
|
|
Саша
23/02/12 17:34
|
|
|
|
|
Здравствуйте. Период обновления данных (таблица заявок, стаканы и т.п.) и раундтрип транзакции (подача транзакции и получение ответа) не связаны, т.к. это разные и изолированные друг от друга потоки, соответственно сравнивать
»»»
Здравствуйте. Период обновления данных (таблица заявок, стаканы и т.п.) и раундтрип транзакции (подача транзакции и получение ответа) не связаны, т.к. это разные и изолированные друг от друга потоки, соответственно сравнивать их некорректно. По периоду обновления данных мы проанализировали логи рекомендовали Вам обратиться к брокеру для продолжения анализа, т.к. на клиентском месте проблем обнаружено не было. По раундтрипу транзакции требуется отдельный анализ (в случае необходимости) и, с высокой долей вероятности, также без обращения к брокеру точную картину составить не удастся.
|
|
Олег Хуснутдинов, ARQA Technologies
24/02/12 13:52
|
|
|
|