Quik2Quant - Release - Вопросы. StockSharp

Quik2Quant - Release - Вопросы

11/24/2010

zyko

Добрый день, у меня есть список вопросов к разработчику адаптера, буду рад, если ответите по пунктам. Я недавний пользователь OQ, но давний пользователь Quik. Использую программы: OQ версии 2.9.12, Quik версии 5.18.0.127, Quik2Quant (версия 1.24.2910.1015, сборка от 14 октября) с демо-лицензией. Время машины синхронизировано с мировым временем и, визуально, с временем сервера Quik.

1. В настройке адаптера предусмотрено поле Account, "по умолчанию, все заявки отправляются по счету, указанному в этом поле". Вообще, в квике, при отправке заявки по "акции" необходимо указывать Код клиента и Счёт депо, а при отправке заявки по "деривативу" достаточно только Торгового счета. Я правильно понимаю, что это поле соответствует счёту депо для акций и торговому счёту для деривативов, то есть подставляется в параметр ACCOUNT транзакции квика? И что для одновременной торговли и акциями и деривативами этого поля будет недостаточно? Или адаптер автоматически определяет какие-то поля из таблиц позиций? Если да, то как он различает бумаги для нескольких кодов клиента и нескольких срочных счетов в одном терминале (иными словами, поддерживается ли адаптером множественность счетов)?

2. Запускал адаптер на своём рабочем счету, но не добавил всех инструментов в ТТП. Возникло явно избыточное количество записей в Provider Errors вида "инструмент с кодом ... не найден" с дублированием кодов инструментов. Почему при наличии позиций по примерно 30 инструментам, количество ошибок перевалило за 200 и вроде как не собиралось останавливаться? Неужели адаптер парсит таблицы заявок и сделок, и по каждой записи производит проверку, вне зависимости от того, что по данному инструменту уже была дана диагностика?

3. При корректной настройке всех таблиц Quik подключение адаптера даёт две одинаковые записи в Provider Error: "элемент с тем же ключом уже был добавлен". Непонятно, какой элемент, с каким ключом, куда был добавлен? Это ошибка или нет? При этом первая запись появляется сразу после Connect, а вторая - примерно через полторы-две минуты в тот момент, когда адаптер завершил все проверки и данные начали поступать в OQ.

4. Правильно я понимаю, что Replace на FORTS всё ещё нельзя использовать? Ведь, как написано в примечании 1 в разделе "Изменения", цена в заявке не меняется, а нам как раз только изменение цены и нужно.

5. Не смог работать с окном Data -> Import -> Historical Data. Насколько я понимаю, поскольку квик интрадейная система, запрос истории возможен в пределах текущей торговой сессии и происходит обработкой таблицы всех сделок. При нажатии Download статус процесса меняется на Downloading и можно ждать сколько угодно - ничего не меняется. Нажатие на Stop не помогает. Поскольку окно закачки исторических данных - модальное, оно блокирует весь интерфейс OQ, что лечится только убиванием процесса программы. Вопрос: реализована работа с HistoricalData? Текущая версия поддерживает исторические запросы GetHistoricalBars(Trades)?

6. Data Capture корректно заполняет все типы данных: тики, бидаски, свечи, стаканы. Однако полученные свечи в итоге не совпадают со свечами в квике. Различия небольшие, сравнение таблицы всех сделок со списком тиков в OQ показывает, что тикам присваивается локальное время их поступления в OQ, а их собственное время не используется. Так ли это? Если так, то на формирование графика влияют любые задержки экспорта DDE и "замирания" данных. Например, отключение квика на полчаса при включении даёт огромную свечу, куда входят все тики за этот период. Параметр EnableTimeCheck не очень спасает, потому что для меня ключевым моментом является полная тождественность формируемого графика данным биржи. Даже в квике графики формируются по времени самих тиков, ведь эта информация поступает в OQ! Вопрос: как в целом реализована работа с таблицей всех сделок? Что происходит при перезапуске квика? Это зависит от EnableTimeCheck? Если EnableTimeCheck = false, то в OQ попадают заново все тики?

7. В мануале написано, что при "повторном включении OQ связи между стратегиями и активными заявками теряются" и предложено снимать активные заявки, где-то их сохранять, а затем загружать обратно в стратегию. Снятие, сохранение и загрузка заявок должны, видимо, происходить непосредственно самой стратегией, иначе возможные изменения статусов заявок останутся неотработанными стратегией. Правильно я понимаю, что эту логику надо размещать в обработке события OnStrategyStop?

8. Что происходит с заявкой при потере ответа на транзакцию? При работе с TRANS2QUIK.dll обычно возникали две сложные ситуации: когда возвращался код ответа 12 и когда ответ на транзакцию вообще не приходил, терялся. В OQ в первом случае, видимо, статус заявки станет Reject? А во втором случае? Ведь в OQ никакого таймаута ожидания, как в QPILE, нету, что - заявка так и останется с бесконечным статусом New?

С уважением,
Николай.

Tags:

клуб алготрейдеров

Thanks:

1 2 3 >

Pike

Date: 11/25/2010

Доброе время суток, Николай

1) Поле CLIENT_CODE не является обязательным параметром при формировании строки заявки (см. руководство пользователя Quik, раздел "Формат .tri-файла с параметрами транзакций"). Счет, который указан в параметрах адаптере сделан для создания возможности отправлять заявку "руками" (из Quite Monitor это можно сделать нажав правую кнопку мыши по инструменту, по которому собираетесь отправлять заявку), т.к. при формировании заявки подобным образом нет поля "Счет".

Quote:

Я правильно понимаю, что это поле соответствует счёту депо для акций и торговому счёту для деривативов, то есть подставляется в параметр ACCOUNT транзакции квика?

Да.

Quote:

...поддерживается ли адаптером множественность счетов

Да, множественность счетов возможна. Когда вы в стратегии в OpenQuant создаете объект Order для отправки торгового приказа, то в нем доступно поле Account, по которому и будет отправлена данная конкретная заявка. Если в объекте Order счет не указан явно, то будет использован счет из настроек провайдера Quik2Quant. Таким образом вы можете для каждого конкретного ордера указывать свой счет.

2) Все таблицы, которые экспортируются для нужд Quik2Quant-провайдера должны быть синхронизированы по инструментам. Ошибки возникают в связи с тем, что вновь поступающие сделки, заявки, собственные сделки не находят соответствующей информации по инструменту из ТТП. Я рекомендую вам использовать для настройку для Quik, которая приложена в архиве с Quik2Quant. Если помимо автотрейдинга вам необходимы другие таблицы/графики, то я рекомендую вам создать отдельную вкладку в Quik и создать дубликаты необходимых вам таблиц.

3) Вам нужно активировать логирование работы адаптера в файл и при повторении ошибки выслать его на Quik2Quant@qmail.com (лучше в zip-архиве). После этого можно будет более точно определить источник ошибки.

4) С методом Replace на момент реализации текущей версии Quik2Quant на стороне OpenQuant была проблема. Если вопрос с ценой заявки будет решен со стороны разработчиков OpenQuant, то можно будет использовать метод Replace не только с площадкой FORTS для лимитных ордеров (одна транзакция), но и для спот, причем и для стоп-заявок в том числе (2 транзакции). Это сделано для удобства манипуляции заявками из стратегии. К примеру, если вам нужно будет переместить скользящий стоп-ордер, то вы можете вызвать метод Replace, а не отправлять приказ на снятие заявки, дожидаться снятия заявки (через изменение OrderStatus) и генерировать новую заявки. Причем метод Replace так же будет работать, если у выставленной вами стоп-заявки уже исполнилось условие и она попала на сервер биржи в виде лимитного ордера.

5) Импорт исторических данных не реализован в текущей версии провайдера (даже за текущую сессию). Нами сейчас рассматривается ряд возможных решений, в рамках которых можно будет загружать данные за произвольный интервал. Этот функционал ВОЗМОЖНО будет добавлен в более поздних версиях провайдера. На текущий момент можно воспользоваться импортом данных из текстовых файлов, предварительно скаченных например с FINAM

6) Да, вновь поступающим тикам присваивается локальное время (используется рекомендуемый разработчиками OpenQuant объект Clock). Бары в OpenQuant формируются "внутри", исходя из тиков и API OpenQuant не содержит методов, с помощью которых можно передать программа Бар.

Quote:

...отключение квика на полчаса при включении даёт огромную свечу...

Этого не должно произойти при включенном фильтре EnableTimeCheck поскольку как только Quik "отомрет" поток пропущенных сделок, у которых время отстает от локального более чем на TimeShift будут игнорированы. Соответственно, при формировании бара будет потеряна часть трейдов (которые проигнорировались). Если необходимо, опишу более детальный пример. Если при рестарте Quik в течение сессии вы не включили EnableTimeCheck, то все сделки с начала дня со своим (биржевым) временем начнут поступать в провайдер и с измененным временем на локальное поступят во все объекты OpenQuant. Очевидно, что будет грубо нарушена логика работы - сделки с начала дня будут восприниматься как вновь поступающие.

7) Да. Загрузка ордеров, которые были активны до выключения OpenQuant целесообразно оформить в обработчике OnStrategyStart, а сохранение - в OnStrategyStop

8) Если по заявке пришел отчет об ее отклонении (вне зависимости от причин), но заявка в OpenQuant будет иметь статус Rejected. Если по отправленной заявке не пришло никакого ответа от сервера, то статус заявки будет PendingNew. Статус заявки изменяется на New только тогда, когда от сервера получен ответ об успешной постановке

С уважением

Thanks:

zyko

Date: 11/25/2010

1. Ваш ответ я понял. Остался вопрос про множественность счетов. Например, у меня есть два пользовательских соглашения с брокером. Или просто субсчета на ММВБ. При их подключении к одним ключам Quik это означает появление нескольких кодов клиента в спот-таблицах. При этом у всех кодов клиента обычно одинаковый счёт депо. При этом указание CLIENT_CODE становится необходимым. Как в этом случае отправить заявку по нужному коду клиента? (видимо, никак, поскольку в OQ у заявки есть только одно поле Account)

2. В архиве Quik2Quant были папки Help, Licensing, набор dll и xml файлов. Настройку для Quik я не увидел (видимо, это должен быть exe-файл).

5. Проблема предварительного импорта данных через отдельный менеджер в том, что для работы реальной стратегии нужны данные за последние N интервалов ВПЛОТЬ ДО момента начала работы стратегии. Никакой ручной экспорт не обеспечит непрерывности. Отсутствие поддержки функций GetHistoricalBars(Trades) серьёзно ограничивает применимость адаптера для меня. Вопрос: возможные варианты реализации работы с историческими данными будут оперировать только текущей сессией или задумано "склеивание" данных с прошлыми сессиями? (второе было бы очень круто) Конечно, можно включать на всё время сессии DataCapture, но здесь возникнет вопрос корректности этих данных:

6. Поскольку таблица всех сделок очень большая, у меня даже при максимально синхронизированном времени компьютера и биржи некоторые тики отставали от реального времени до 3 секунд. Эти задержки плавающие и непредсказуемые. Я смотрел их в DataCapture у четырёх инструментов. Боюсь, что при паре десятков инструментов и запуске кучи проектов задержки могут стать ещё больше. Вопрос: какие вы видите способы "приближения" времени поступающих в OQ тиков к их "биржевому" времени? Может быть какие настройки файла info.ini секции DDE?

6а. Если все сделки никак не используются для HistoricalData, то непонятно, зачем нужна возможность EnableTimeCheck = false? Это же лишняя нагрузка на OQ, которая в любом случае "грубо нарушает логику работы".

8. При отклонении заявки где-нибудь можно увидеть причины этого? А именно то, что в Quik возвращается в полях RESULT_EX и DESCRIPTION? Может быть, в Provider Errors или как ещё? Просто эта информация может быть использована в алгоритме.

8а. К сожалению, в системе Quik нет контроля за ответами на транзакции. Самые сложные случаи в работе происходили как раз тогда, когда ответ на транзакцию просто терялся, не приходил. Видимо, в этом случае я сам должен принимать решение, сколько времени заявка может быть в статусе PendingNew? Или посоветуйте, как ещё можно поступать в такой ситуации?

Thanks:

Mikhail Sukhov

Date: 11/25/2010

Добрый день!

Я не автор адаптера, но логику работу постараюсь объяснить на низком уровне S# (на нем построен данный адаптер).

zyko

6. Поскольку таблица всех сделок очень большая, у меня даже при максимально синхронизированном времени компьютера и биржи некоторые тики отставали от реального времени до 3 секунд. Эти задержки плавающие и непредсказуемые. Я смотрел их в DataCapture у четырёх инструментов. Боюсь, что при паре десятков инструментов и запуске кучи проектов задержки могут стать ещё больше. Вопрос: какие вы видите способы "приближения" времени поступающих в OQ тиков к их "биржевому" времени? Может быть какие настройки файла info.ini секции DDE?

Экспорт тиков стартует тяжело. В первые секунд 10-15 (на моем компьютере при 3-ех инструментах) происходит 100% нагрузка из-за того, что передаются пакетами в 16 тыс. сделок в адаптер. Этот процесс не постоянен, и когда передача дойдет до текущих тиков нагрузка упадет (возможно до 0). Так что отставание должно прекратиться. Я думаю в этот момент и наблюдаются как раз те самые отставания.

zyko

8а. К сожалению, в системе Quik нет контроля за ответами на транзакции. Самые сложные случаи в работе происходили как раз тогда, когда ответ на транзакцию просто терялся, не приходил. Видимо, в этом случае я сам должен принимать решение, сколько времени заявка может быть в статусе PendingNew? Или посоветуйте, как ещё можно поступать в такой ситуации?

Это не совсем так. Квик как раз прекрасно отвечает на поступившие транзакции (присылает и код, и описание ответа). Есть ситуации, когда Квик не отсылает ответ (в момент обрыва связи). Но это очень редкое явление. Может Вы опишите симптомы, когда такое у Вас случилось, в что было в этот момент с сами Квиком (главное, появилась ли такая заявка в таблице Заявки).

Thanks:

Pike

Date: 11/25/2010

1. В текущей версии адаптера - да, CLIENT_CODE нельзя передать в объекте Order. Возможно нам стоит рассмотреть вариант передачи кода клиента через Свойство Text объекта Order (хотя это не есть его прямое назначение). Если у вас есть какие-то еще варианты решения данного вопроса - предлагайте, мы обязательно рассмотрим.

2. В скором времени у провайдера Quik2Quant будет дистрибутив. Появиться ряд изменений и дополнений, самый существенный из которых - функционал для импорта инструментов из Quik.

5. Почему бы вам не рассмотреть следующую схему работы:
1) Импорт исторических данных с ФИНАМ по инструменту
2) При старте стратегии заполнение необходимых серий импортированными данными (будет осуществлен предрассчет индикаторов и зависимых объектов)
3) Включаем DataCapture.
Таким образом, у вас будут во внутренней базе храниться накопленная история, к которой вы сможете обращаться

6а. Опция осталась от более ранних разработок - в следующей версии уберем. Правда "нагрузка" от этого не изменится - просто у пользователя не будет возможности выключать проверку на время вновь поступившего тика. Останется только TimeShift.

8. Текст ошибки доступен в Reports.

С уважением.

Thanks:

zyko

Date: 11/25/2010

Mikhail Sukhov

Разве экспорт идёт не последовательно от первой записи? Если последовательно, то появление текущих тиков в OQ должно быть после прокачки тех огромных пакетов (кстати, тики начинают поступать в OQ через несколько минут после подключения адаптера). Если нет, то Вы правы, надо подождать. Вообще, я спрашивал про настройку параметров, о которых сказано http://www.quik.ru/forum/iwr/55471/58462/#m58462 , сам я с DDE не работал.

Mikhail Sukhov

Пожалуйста, с удовольствием опишу.
Я очень долго работал с квиком. Как через QPILE, так и через TRANS2QUIK. Самыми сложными случаями для разбора становились именно те, когда ответ на транзакцию не приходил. При этом в синхронном способе отправки транзакций срабатывал указанный явно таймаут (тот самый код ответа 12 сервера квик), а в асинхронном можно было ждать до второго пришествия - коллбек не приходил. Поскольку таймер в любом случае запускается на стороне клиента, можно говорить, что это один случай - когда ответ не приходит.
Причины я могу перечислить такие:
- обрыв связи на любом участке до ТС (бывало что глючили и наши провайдеры, и провайдеры брокера, а бывали сбои в датацентрах)
- глюки ПО биржи (в том числе и шлюзов, это вообще страшное дело, вот недавно у одного брокера было: маркет-дата приходит нормально, а все транзакции пропадают с концами)
При этом факт выставления заявки по потерянной транзакции - вероятностен! Очень часто заявки регистрировались и исполнялись.
Для борьбы с потерянными заявками у меня сейчас реализовано два алгоритма:
1) Робот пытается найти потерянную заявку, используя time, trans_id и таблицу заявок.
2) Ведётся онлайн сравнение суммарно всех позиций роботов и текущих позиций на счёте.
Конечно, многое зависит от качества обслуживания серверов квик брокером. Например, на публичных серверах БКС проблемы были еженедельно. Сейчас у меня нет проблем с серверами, и теперь я могу сказать, что потери ответов стали "очень редким явлением", но избавиться от коррекции вручную на 100% всё равно не получилось.
В случае работы через OQ нет ни trans_id, ни таблицы заявок, поэтому я и хочу понять, как в OQ мне реализовывать аналоги моих алгоритмов контроля.

Thanks:

zyko

Date: 11/25/2010

Pike

При этом поле Text станет напоминать поле COMMENT транзакции квика, то есть для сохранения возможности что-то в нём написать придётся вводить разделитель <код_клиента>|<метка>. Однажды я использовал тот факт, что трейдер обычно работает с одним счётом депо, и передавал в account код клиента для спотовых бумаг, а счёт депо прописывал в отдельном поле, но это, конечно, не очень красиво.

Pike

5. Почему бы вам не рассмотреть следующую схему работы:

Как я уже писал, не будет непрерывности.
Импорт данных с финама занимает какое-то время, минуты. Плюс возможная задержка в самих данных. Плюс время на импорт в OQ. Это далеко от автоматизации.
Но самое главное: на следующий день с финама подгрузятся иные свечи, чем были сгенерированы в процессе импорта тиков из квика.
А вариант хранить все сгенерированные из квика свечи в базе OQ требует почти круглосуточной непрерывной работы комплекса, чего я не могу гарантировать.

Pike

8. Текст ошибки доступен в Reports.

Не могу найти такого слова в описаниях. Это окно ProviderErrors, лог адаптера или что другое?

Thanks:

Pike

Date: 11/25/2010

Quote:

Но самое главное: на следующий день с финама подгрузятся иные свечи, чем были сгенерированы в процессе импорта тиков из квика.

В OpenQuant, в любом случае будут отклонения данных в барах от "идеала". И в стратегию будут поступать именно эти "неидеальные" бары. Соответственно и анализ нужно будет строить исходя из них. OpenQuant бары формирует внутри себя из тиков и на этот механизм повлиять нельзя.
Плюс к этому, квик не передает данные по свечкам.

Quote:

Не могу найти такого слова в описаниях

В Order Manager доступны Reports по заявкам

Thanks:

zyko

Date: 11/25/2010

Pike

В OpenQuant, в любом случае будут отклонения данных в барах от "идеала".

Да, я всё понял, буду думать.

Спасибо за ответы.

Thanks:

Mikhail Sukhov

Date: 11/25/2010

zyko

Экспорт идет от первой до последней записи. Тормозит как раз когда идет пачка сделок, с первой по текущую (именно так, которая появилась в текущую секунду, а не просто за текущую сессию). А текущие, которые появляются каждый раз новые, экспортируются мгновенно. Если у Вас как раз текущие идут с задержками, то это совсем другое дело. Тут нужно отдельно разбираться. Но пока не совсем понятно, какие именно тики у Вас задерживаются.

Mikhail Sukhov

При этом факт выставления заявки по потерянной транзакции - вероятностен! Очень часто заявки регистрировались и исполнялись.
Для борьбы с потерянными заявками у меня сейчас реализовано два алгоритма:
1) Робот пытается найти потерянную заявку, используя time, trans_id и таблицу заявок.
2) Ведётся онлайн сравнение суммарно всех позиций роботов и текущих позиций на счёте.

Как реагирует на это дело адаптер не скажу, но вообще заявки можно отслеживать через два потока. Первый - это непосредственно их создание, второй - экспорт по ДДЕ (например, когда трейдер торгует на пару с роботом). Городить огород для проверок я думаю пока рановато (уж больно редки ситуации намного проще просто оповещать о таких редких ситуациях роботовода). Тем более что Квик постоянно фиксит баги (им надо лишь детально написать шаги, и тогда 100% к следующему релизу баг исчезнет). Например в 5.18 они исправили закоренелую проблему с быстрой перестановкой заявок. А баг был очень и очень назойлив.

Thanks:

Mikhail Sukhov

Date: 11/25/2010

Pike

OpenQuant, в любом случае будут отклонения данных в барах от "идеала".

Я так и не понял почему.

Pike

И в стратегию будут поступать именно эти "неидеальные" бары. Соответственно и анализ нужно будет строить исходя из них

В кванте можно подписаться на событие новых тиков?

Thanks:

1 2 3 >

Attach files by dragging & dropping, , or pasting from the clipboard.