<HELP> for explanation

Блог им. akaRem

Вопрос о стандартных задержках в обновлении данных QUIK/QPILE

Хочу написать торгового робота на языке QPILE, но торговый алгоритм несколько критичен к системным задержкам и рассогласованиям.
(Не ХФТ, но нужно четко контролировать позиции по инструментам, активные и исполненные заявки, а так же совершенные сделки с наименьшими «тормозами»)

Подскажите, пожалуйста, какие задержки являются нормальными (понятно, что они всегда есть, интересуют их «обычные» величины — от… до… )
— между двумя последовательными итерациями скрипта (и что будет, если его зациклить на постоянный пересчет?) (1)
— между моментом передачи скриптом заявки на сервер и моментом получения ответа от сервера о результате (2)
— (приостанавливается ли выполнение скрипта до момента получения ответа от сервера)? (2, да)
— между моментом передачи скриптом заявки на сервер и моментом появления заявки в таблице заявок (т.е. моментом начала возможности проверять наличие и статус заявки в системе) 
(3)
— между моментом исполнения(удовлетворения) заявки на бирже и моментом изменения ее статуса на «исполнена» в таблице заявок (3)
— между моментом исполнения(удовлетворения) заявки на бирже и моментом ее появления в таблице сделок (3)
— между моментом исполнения(удовлетворения) заявки на бирже и моментом изменения позиции по счету, списания/начисления ГО и изм. прочих параметров. (речь идет о фьючерсных контрактах) в таблице позиций по клиентским счетам и таблице ограничений по клиентским счетам (3)

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

Возможна ли ситуация, когда нарушается порядок заявок и сделок в таблицах? Например,
— отправил заявку1, потом заявку2 и заявку3, в таблице отображаются в порядке типа заявка1, заявка3, заявка2
— заявки исполнились в порядке заявка1, заявка2, заявка3, в таблице сделок отражается в порядке типа сделка1, сделка3, сделка2 (4)

По каким таблицам лучше контролировать свои заявки и позицию? (5)

Если на СмартЛабе (или где-то еще) есть что почитать на эту тему, буду признателен за ссылки.

ПС. Я в курсе, что СтокШарп — это хорошо, Купайл — плохо и т.п. Но вопрос именно про Купайл.
ППС. Программист, но на Купайле пока не писал.

________________________

Ответы от Арки 

1) Минимальный промежуток между итерациями = 1 сек.
Время расчета одного цикла = время работы самого портфеля + интервал между итерациями.
То есть, отсчет интервала, начинается как только портфель закончил работать а не как только начал.
Если портфель зациклить то это будет одна итерация, которая никогда не кончится, соответственно интервал можно указать любым.

2) Есть минимальный промежуток, в течении которого портфель будет ждать ответ на транзакцию wait_timeout_for_replay (не менее 5 сек.) Это означает, что когда портфель отправит транзакцию, он будет ждать минимум 5 секунд пока не продолжит свою работу. Если он получит ответ раньше, то работа продолжится. Если по истечении этого времени, ответа об успешной отправке не будет, то в RESULT_EX вернется ошибка.

3) Это время целиком и полностью зависит от качества и скорости канала связи между Вами и брокером. Если связь хорошая и проблем со связью не наблюдается, то заявка появится за доли секунды. Точнее сказать не можем. Однако, есть нюанс, обновление данных по деньгам и бумагам (для фьючерсов позиции и ограничения) приоритетнее чем обновление таблиц с заявками и сделками. То есть деньги заблокируются под заявку на сотые доли быстрее чем появится запись о заявке.

4) Да такая ситуация возможна, но шансов ее возникновения практически нет. Зачастую такие ситуации проявляются при задержках на канале связи. Все зависит опять же от качества канала связи.

5) лимиты по деньгам и бумагам (для фьючерсов позиции и ограничения).
 

на купайле задержка от одной секунды и выше
avatar

Maaxee

Maaxee, 1 сек — по идее ок, и, в принципе, 5-10 перетерпеть — вроде как тоже не особо проблемно (не ХФТ). :)
Основное, что интересует: на какую производительность реально имеет смысл рассчитывать алгоритмы и коэффициенты, и какие дынные стоит перепроверять (мало ли что там в квике возможно) — отсюда растут ноги точности приказов, ММ, и доходности с одной стороны; и сложности алгоритмов — с другой.
akaRem, нормально там всё, за секунду уложится любой алгоритм (расчет данных, выставить/снять/подвинуть) всё умещается в 1 сек. не заморачивайся с задержками. Писать лучше в этой программе(синтаксис VB выбрать), там всё красиво выделяется цветов и групируется по циклам, блокам и т.д., можно удобно скрывать/раскрывать блоки. освоить квик в отличии от С# можно за 1 день, для простых систем(без трёх мерных интегралов) самое то.

Роботорговец, Да, знакомая прога. Пользуюсь.
А как ты (можно на ты?) отслеживаешь тек. позицию и заявки?
akaRem, ну смотрю есть ли активные заявки в таблице заявок.
N=GET_NUMBER_OF(«ORDERS») ' ПОЛУЧАЕМ ЧИСЛО СТРОК В ТАБЛИЦЕ ЗАЯВОК
IF N>0 ' ЕСЛИ ТАМ ЧТО-ТО ЕСТЬ, ТО
FOR I FROM 0 TO NKILL
IF (GET_VALUE (GET_ITEM («ORDERS», I), «STATUS»)=«ACTIVE»… то смотрим сколько лотов осталось и решаем что с этим делать. в интернете полно примеров готовых роботов и блоков
Роботорговец, в общем так же как Maaxee и Dimanite пишут?
Спасибо.
akaRem, наверное, не знаком с их работами.
Роботорговец, да ты не стесняйся — давай дружить! Я вообще открытый для создания команды адекватных людей! И пофиг чем мы будем заниматься, если мы адекватные люди :) А если мы еще и одним делом займемся! То вообще крутотенечка :)
Dimanite, мы в разных городах. ты в москве на мкаде, а я в россии, у нас такси 100р. и квартира 500тр стоит, даже курс рубля разный.)))
Роботорговец, ну я тоже не знаком… тут ниже пишут.
akaRem, я круто! Блин… поверь мне!!! :)))))))))))))
Роботорговец, а не в курсе, как отрабатывается функция отправки заявки, если wait_timeout_for_replay поставить меньше 5 сек? (арковцы говорят, что 5 — это вроде как мин. значение)
akaRem, заявки испольняются мгновенно если у вас хороший компьюетр(хотябы 3-х летней давности) и интеренет будет 1мс.
Этот параметр служебный на скорость исполнения не влияет. На квике можно делать ХФТ, там нет ограничений, проблема тока в интернете и кривых руках(кто любит в циклы задержки добавлять)
Роботорговец, спасибо, кстати, оф. ответ от Арки — меньше 5 сек писать нельзя. Если канал хороший, то исполняются они за доли секунды. Т.е. такой же. :)
нет там инструментария для столь детальной информации о лэтэнси, все работает с мин тактом 1 сек
hush, такт 0 сек, зависит от вашего компьютера и интернета. Вы в конце цикла не ставьте задержку 1сек, будут милисекунды как в С#.
Роботорговец, такт 0 сек забавно звучит))) в остальном согласен
hush, я имел ввиду тот такт про который имелии ввиду: что к времени исполнения программы 100мс + 1 сек искуственно., можно и час задать в квике есть и такие возможности
Роботорговец, т.е. если 1 сек искуственно не ставить, бедет каждые, например, 100 мс считать?
hush, имеется в виду внутри скрипта сделать «вечный цикл» — тогда внешние настройки через сколько его запускать роли не играют — он как запустился — так и крутится.
hush, если у вас быстрый комп и интернет то будет и 1 мс почти ХФТ. такт будет зависеть только от железа, но только чтобы не считалось эта +123456… сек, надо в конце самого последнего цикла указать что испольнять программу заново, а не переходить в искусвенную задержку цикла в настройках квика(0 поставить нельзя, можно не включать просто это)
hush, ну то что на сверхскорости рассчитывать не приходится — это понятно. Про минимальное время — тоже.
А вот что там с верхними пределами?
И где ловить исполнение ордеров?
akaRem, я прям таблицу заявок сканирую.
Maaxee, а данные там актуально обновляются?
__

У меня эти вопросы вообще возникли, т.к. помню, что в Квике ГО как-то неспешно пересчитывалось — поэтому хз, как там все остальное рассчитывается…
akaRem, всё там по человечески обновляется.
akaRem, ну для начала есть алгоритм пересчета ГО, и он не меняется каждую минуту — поверьте :)
арбитраж?
avatar

Konstantin

Konstantin, нет, не арбитраж и не парный. :)
Робот на C#, средний раундтрип 250 миллисекунд.
avatar

ivan_petrov

ivan_petrov, это хорошо, но см. пост — вопросы о купайле…
C# не знаю и знать не хочу :)
akaRem,
> C# не знаю и знать не хочу
Стратегическая ошибка. Все придется переписывать заново, если надо будет менять платформу.
ivan_petrov, согласен, при смене платформы придется переписывать.
Но, с одной стороны, менять вроде бы нет необходимости, а с другой — я отлично знаю другие языки и посему изучать .Net C#-клинопись необходимости не вижу.
Выбрал купайл только потому что хочу уменьшить количество прослоек между роботом и торговлей, что принесет большее моральное спокойствие. :)
ivan_petrov, если менять то конечно это супер проблема, но кому это надо? Кто менял квик в последние 10 лет? Ну да я менял — был квик, потом альфа директ и снова квик! Ну надо же!
в среднем по России от Вас до биржи — 0.1 сек
avatar

cruss1u5

там 5 сек нужно минимум для выставлении заявки (на купиле рекомендуют)
avatar

cruss1u5

cruss1u5, кто где 5 сек рекомендует? Нет ли ссылки, случайно?
akaRem, на арке на сайте справка по купайлу…
я меньше делал — оно не ругалось… а в эктрим как-то не посчастливилось попадать
akaRem, Функции для работы с заявками — в этом подразделе
раздела «алгоритмический язык»

www.quik.ru/depot/chm_quik.zip
cruss1u5, а, да, действительно. Проглядел этот момент.
А выполнение этой функции, я так понимаю, приостанавливает скрипт до получения ответа от сервера, так?
akaRem, вроде нет… но надо контролировать потом запросам встала заява или не встала
cruss1u5, вообще там в справке неудачно расписано, т.к. параметр называется «wait_timeout_for_replay» — т.е. по названию — вроде как для повтора заявки, а по описанию — ожидание ответа. Т.е. вроде как логично поставить 0 чтоб не ждать ответа и искать заявку в заявках, но если это таймаут на повтор, то получится фигня полная…
посл абзац (вопрос): не понял вопроса, но если по одному инструменту, то вроде бы как нет… если разные инструменты, тем более площадки, то возможно да

пред посл. (вопрос): возможны — лично видал задупливания… но там не через скрипты выставлял а через импорт но на купайле — а на купайле можно контролировать это
avatar

cruss1u5

cruss1u5, а я ответов не очень понял. ))
первый ответ про нарушения очередности заявок/сделок? Если так, то про разные площадки — логично, про один инструмент — спасибо.

второй ответ — про рассогласования таблиц? А в каких местах «задупливания» были?
akaRem, пример:

отправляем заявку
если она не встала отправлем еще раз

// тут первая строчка уже вставила ордер, и вторая вставила
опс! две заявки стоят…

но это решабельно, хотя на времени сказывается
akaRem, таблицы? нах они нужны?…
cruss1u5, где-то что-то уже посчитано -> можно в скрипте не считать.
Проверить, правильно ли что-то отображается, сверив в нескольких местах.
Вопрос в том, где на данный момент что правильно посчитано.
cruss1u5,… я понимаю, что у меня много странных и бестолковых вопросов, но это потому что опыта пользования купайлом еще нет, а отношение к нему достаточно скептическое. ))
Задержки там есть это однозначно. Во-первых время исполнения программы — если у вас стоит выполнять раз в 1 сек это означает, что идетзапуск проги на купайле она выполняется и после окончания выполнения проги отсчитывается 1 сек. То есть если ваш код большой он может сильно есть время машины. Купайл это интепретатор и его писали не для того что бы сильно шибко и быстро считать. Тем более он очень чуствителен к типизации. Исполненые заявки то же не сразу могут появляться в таблице заявок как исполненые — здесь может быть задержка так как может быть экономия трафика — у меня лично в 2008 году в Атоне задержка была около 2-3 секунд. Вообще если есть вопросы пишите в личку — со мной можно свзяаться и я попробую помочь разобраться. Возможно есть другой путь для Вашего алгоритма
avatar

usertrader

usertrader, не испытываю неприязни к скриптовым языкам — сам питонист :) То что купайл работает медленно — это, конечно, совсем не удобно, но, с другой стороны, от него много не требуется (а там много и не напишешь с его синтаксисом) — читать директивы, выполнять необходимые телодвижения и контролировать позицию, да и стратегия, опять же, не ХФТ.

… а 2-3 сек задержки — это у вас на что было? почему?
akaRem, о и мне пишите в личку! :)
Dimanite, нет, давайте уж здесь! :)
что-то вы тут все усложняете… какие нах циклы? Вы квик этим вообще повесите!

Кароч система простая:
обычно робот обновляется 1/2 секунды (редко но бывает 3 секунды)
смотри таблицу выставленых заЯВок, запоминай номер, и смотри — если номер заявки исполнен полностью, тогда обновляй баланс (я его вообще отдельно от брокера считаю и храню — так то оно безопаснее, просто я его сравниваю иногда с официальными данными но не принимаю решения основываясь только на них)

Я так понимаю ты хочешь отправлять сразу же 3 заявки… я не буду отвечать тебе на вопрос, но спрошу — а зачем? И есть ли в этом алгоритм?

Если тут есть алгоритм, например заявка 1 исполнилась — баланс равен 1 контракт, цена снизилась на 1% купили еще 2 контракта (отправили заявку, исполнилась, обновили баланс), теперь у нас есть новая средняя величина по балансу, цена уже от обновленной средней цены снизилась на 1% и мы купили еще 3 контракта (заявка, исполнилась, обновили баланс).

Суть я думаю ты уловил. Возможно стоит делать все поступательно а не сразу пул заявок контролировать — ибо это сложнее
avatar

RidayTrader

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

Если брать описанную ситуацию, как пример, то в случае когда цена спайканула, ордера исполнены, но позиция еще не изменилась, и робот по логике должен закрыться, он может начать пытаться вместо закрытия позиции выставлять новые ордера, на которые будет не хватать ГО… или наоборот откроет, а потом узнает, что позиция совсем не такая как надо и начнет чудить.
Что-то вроде этой ситуации предусмотреть можно, но могут быть и какие-то другие косяки.
Поэтому хочется определиться с тем, как лучше сделать, чтобы было как можно меньше проблемных мест. Тем более что с Купайлом у меня пока нет опыта косяков.
akaRem, «цена спайканула, ордера исполнены, но позиция еще не изменилась» ну как так не изменилась позиция. У вас есть исполненная заявка, и есть ее объем, и есть понимание какая позиция была перед этим. Тут проблемы нет вообще.
Ну как следствие не вижу причин далее смотреть проблему, так как на этом этапе она вроже как решилась.

Вопрос: как система принимает решение на открытие новой позиции? Думаю если тут логика чОткая то все нормально будет
Dimanite, "«цена спайканула, ордера исполнены, но позиция еще не изменилась» ну как так не изменилась позиция" — это если я читаю позицию в таблице позиций по клиентским счетам (но теперь я уже знаю, что я так делать не буду и никто так не делает)… а вообще, да, не совсем удачный пример, пожалуй привел.
«как система принимает решение на открытие новой позиции?» — в файле написано открыть — открывает. ЧОтче некуда! =)
akaRem, в файле??? WOW эффект просто… не страшно? Я имею в виду что теперь необходимо после проверки исполнения заявки не баланс обновить в первую очередь, а файл удалить а потом уже баланс обновить — а то случится косяк :)
Dimanite, файл — как план на день — при каких условиях, по каким инструментам какие позиции должны быть, типа того что написано, что по РИ 130000 в 12:00 должно быть 2 лонга — вынь и полож 2 лонга. :)
… ну образно ;)
akaRem, хм… ну а робот то как принимает решения?
Dimanite, это секрет. :)
Если робот будет убыточным — обязательно расскажу всю схему! ))))
Заапдейтил пост, т.к. пришли официальные ответы от Арки.
avatar

akaRem

akaRem. Вы пишете робота. Технология такова, что получение данных идет различными потоками. Правильный стиль заключается в предположении, что запаздывание данных может быть произвольным. Робот есть конечный автомат. Только в этом случае получается стабильная программа. Любые предположения о максимально возможной задержке являются ошибочными и в конечном счете ведут к неправильной работе и, следовательно, к убыткам.
s_mike@rambler.ru, хорошая мысль, спасибо.

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.

Залогиниться

Зарегистрироваться
....все тэги
Регистрация
UP