Вопрос о стандартных задержках в обновлении данных 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) лимиты по деньгам и бумагам (для фьючерсов позиции и ограничения).
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»… то смотрим сколько лотов осталось и решаем что с этим делать. в интернете полно примеров готовых роботов и блоков
Роботорговец, да ты не стесняйся — давай дружить! Я вообще открытый для создания команды адекватных людей! И пофиг чем мы будем заниматься, если мы адекватные люди :) А если мы еще и одним делом займемся! То вообще крутотенечка :)
Роботорговец, а не в курсе, как отрабатывается функция отправки заявки, если wait_timeout_for_replay поставить меньше 5 сек? (арковцы говорят, что 5 — это вроде как мин. значение)
akaRem, заявки испольняются мгновенно если у вас хороший компьюетр(хотябы 3-х летней давности) и интеренет будет 1мс.
Этот параметр служебный на скорость исполнения не влияет. На квике можно делать ХФТ, там нет ограничений, проблема тока в интернете и кривых руках(кто любит в циклы задержки добавлять)
Роботорговец, спасибо, кстати, оф. ответ от Арки — меньше 5 сек писать нельзя. Если канал хороший, то исполняются они за доли секунды. Т.е. такой же. :)
hush, я имел ввиду тот такт про который имелии ввиду: что к времени исполнения программы 100мс + 1 сек искуственно., можно и час задать в квике есть и такие возможности
hush, имеется в виду внутри скрипта сделать «вечный цикл» — тогда внешние настройки через сколько его запускать роли не играют — он как запустился — так и крутится.
hush, если у вас быстрый комп и интернет то будет и 1 мс почти ХФТ. такт будет зависеть только от железа, но только чтобы не считалось эта +123456… сек, надо в конце самого последнего цикла указать что испольнять программу заново, а не переходить в искусвенную задержку цикла в настройках квика(0 поставить нельзя, можно не включать просто это)
ivan_petrov, согласен, при смене платформы придется переписывать.
Но, с одной стороны, менять вроде бы нет необходимости, а с другой — я отлично знаю другие языки и посему изучать .Net C#-клинопись необходимости не вижу.
Выбрал купайл только потому что хочу уменьшить количество прослоек между роботом и торговлей, что принесет большее моральное спокойствие. :)
ivan_petrov, если менять то конечно это супер проблема, но кому это надо? Кто менял квик в последние 10 лет? Ну да я менял — был квик, потом альфа директ и снова квик! Ну надо же!
cruss1u5, а, да, действительно. Проглядел этот момент.
А выполнение этой функции, я так понимаю, приостанавливает скрипт до получения ответа от сервера, так?
cruss1u5, вообще там в справке неудачно расписано, т.к. параметр называется «wait_timeout_for_replay» — т.е. по названию — вроде как для повтора заявки, а по описанию — ожидание ответа. Т.е. вроде как логично поставить 0 чтоб не ждать ответа и искать заявку в заявках, но если это таймаут на повтор, то получится фигня полная…
посл абзац (вопрос): не понял вопроса, но если по одному инструменту, то вроде бы как нет… если разные инструменты, тем более площадки, то возможно да
пред посл. (вопрос): возможны — лично видал задупливания… но там не через скрипты выставлял а через импорт но на купайле — а на купайле можно контролировать это
cruss1u5, а я ответов не очень понял. ))
первый ответ про нарушения очередности заявок/сделок? Если так, то про разные площадки — логично, про один инструмент — спасибо.
второй ответ — про рассогласования таблиц? А в каких местах «задупливания» были?
cruss1u5, где-то что-то уже посчитано -> можно в скрипте не считать.
Проверить, правильно ли что-то отображается, сверив в нескольких местах.
Вопрос в том, где на данный момент что правильно посчитано.
cruss1u5,… я понимаю, что у меня много странных и бестолковых вопросов, но это потому что опыта пользования купайлом еще нет, а отношение к нему достаточно скептическое. ))
Задержки там есть это однозначно. Во-первых время исполнения программы — если у вас стоит выполнять раз в 1 сек это означает, что идетзапуск проги на купайле она выполняется и после окончания выполнения проги отсчитывается 1 сек. То есть если ваш код большой он может сильно есть время машины. Купайл это интепретатор и его писали не для того что бы сильно шибко и быстро считать. Тем более он очень чуствителен к типизации. Исполненые заявки то же не сразу могут появляться в таблице заявок как исполненые — здесь может быть задержка так как может быть экономия трафика — у меня лично в 2008 году в Атоне задержка была около 2-3 секунд. Вообще если есть вопросы пишите в личку — со мной можно свзяаться и я попробую помочь разобраться. Возможно есть другой путь для Вашего алгоритма
usertrader, не испытываю неприязни к скриптовым языкам — сам питонист :) То что купайл работает медленно — это, конечно, совсем не удобно, но, с другой стороны, от него много не требуется (а там много и не напишешь с его синтаксисом) — читать директивы, выполнять необходимые телодвижения и контролировать позицию, да и стратегия, опять же, не ХФТ.
… а 2-3 сек задержки — это у вас на что было? почему?
что-то вы тут все усложняете… какие нах циклы? Вы квик этим вообще повесите!
Кароч система простая:
обычно робот обновляется 1/2 секунды (редко но бывает 3 секунды)
смотри таблицу выставленых заЯВок, запоминай номер, и смотри — если номер заявки исполнен полностью, тогда обновляй баланс (я его вообще отдельно от брокера считаю и храню — так то оно безопаснее, просто я его сравниваю иногда с официальными данными но не принимаю решения основываясь только на них)
Я так понимаю ты хочешь отправлять сразу же 3 заявки… я не буду отвечать тебе на вопрос, но спрошу — а зачем? И есть ли в этом алгоритм?
Если тут есть алгоритм, например заявка 1 исполнилась — баланс равен 1 контракт, цена снизилась на 1% купили еще 2 контракта (отправили заявку, исполнилась, обновили баланс), теперь у нас есть новая средняя величина по балансу, цена уже от обновленной средней цены снизилась на 1% и мы купили еще 3 контракта (заявка, исполнилась, обновили баланс).
Суть я думаю ты уловил. Возможно стоит делать все поступательно а не сразу пул заявок контролировать — ибо это сложнее
Dimanite, я грубо говоря опасаюсь ситуаций, когда у меня должна быть определенная позиция и определенные заявки, но по каким-то причинам есть расхождения с реальными значениями и я накидаю лишних ордеров.
Если брать описанную ситуацию, как пример, то в случае когда цена спайканула, ордера исполнены, но позиция еще не изменилась, и робот по логике должен закрыться, он может начать пытаться вместо закрытия позиции выставлять новые ордера, на которые будет не хватать ГО… или наоборот откроет, а потом узнает, что позиция совсем не такая как надо и начнет чудить.
Что-то вроде этой ситуации предусмотреть можно, но могут быть и какие-то другие косяки.
Поэтому хочется определиться с тем, как лучше сделать, чтобы было как можно меньше проблемных мест. Тем более что с Купайлом у меня пока нет опыта косяков.
akaRem, «цена спайканула, ордера исполнены, но позиция еще не изменилась» ну как так не изменилась позиция. У вас есть исполненная заявка, и есть ее объем, и есть понимание какая позиция была перед этим. Тут проблемы нет вообще.
Ну как следствие не вижу причин далее смотреть проблему, так как на этом этапе она вроже как решилась.
Вопрос: как система принимает решение на открытие новой позиции? Думаю если тут логика чОткая то все нормально будет
Dimanite, "«цена спайканула, ордера исполнены, но позиция еще не изменилась» ну как так не изменилась позиция" — это если я читаю позицию в таблице позиций по клиентским счетам (но теперь я уже знаю, что я так делать не буду и никто так не делает)… а вообще, да, не совсем удачный пример, пожалуй привел.
«как система принимает решение на открытие новой позиции?» — в файле написано открыть — открывает. ЧОтче некуда! =)
akaRem, в файле??? WOW эффект просто… не страшно? Я имею в виду что теперь необходимо после проверки исполнения заявки не баланс обновить в первую очередь, а файл удалить а потом уже баланс обновить — а то случится косяк :)
Dimanite, файл — как план на день — при каких условиях, по каким инструментам какие позиции должны быть, типа того что написано, что по РИ 130000 в 12:00 должно быть 2 лонга — вынь и полож 2 лонга. :)
… ну образно ;)
akaRem. Вы пишете робота. Технология такова, что получение данных идет различными потоками. Правильный стиль заключается в предположении, что запаздывание данных может быть произвольным. Робот есть конечный автомат. Только в этом случае получается стабильная программа. Любые предположения о максимально возможной задержке являются ошибочными и в конечном счете ведут к неправильной работе и, следовательно, к убыткам.
Ольга Тимченко,
Если бы на Форекс было бы хоть что-то очевидно, на планете жили бы одни миллиардеры….
Никогда и ничего здесь не будет очевидно….
Торговля вероятностью…. Не более того….
Банк Авангард
80 700 000 обыкновенных акций
www.e-disclosure.ru/portal/files.aspx?id=1070&type=1
Капитализация на 26.11.2024г: 59,557 млрд руб
Общий долг на 31.12.2022г: 109,920 млрд руб...
📉 Рынок жестко проливают, до таргета в 2400 осталось падать буквально 2% Очень много компаний обновили лои начала СВО, Самолет вообще уже торгуется почти по цене IPO, даже Сургутнефтегаз преф падает,...
ОЗОН Банк (Ozon Holdings plc) — Прибыль 10 мес 2024г: 10,385 млрд руб (+142,44% г/г) ОЗОН Банк (Ozon Holdings plc)
Общий долг на 31.12.2022г: 7,773 млрд руб
Общий долг на 31.12.2023г: 64,275 млрд ...
Вайлдберриз Банк (Wildberries) — Прибыль 10 мес 2024г: 14,319 млрд руб (+18218,20% г/г) Вайлдберриз Банк (Wildberries)
Общий долг на 31.12.2023г: 2,667 млрд руб
Общий долг на 30.06.2024г: 14,359 м...
Банк Приморье — Убыток 10 мес 2024г: 1,114 млрд руб против прибыли 1,512 млрд руб г/г Банк Приморье
250 000 обыкновенны акций
e-disclosure.ru/portal/files.aspx?id=2839&type=1
Капитализация на 26...
Основное, что интересует: на какую производительность реально имеет смысл рассчитывать алгоритмы и коэффициенты, и какие дынные стоит перепроверять (мало ли что там в квике возможно) — отсюда растут ноги точности приказов, ММ, и доходности с одной стороны; и сложности алгоритмов — с другой.
А как ты (можно на ты?) отслеживаешь тек. позицию и заявки?
N=GET_NUMBER_OF(«ORDERS») ' ПОЛУЧАЕМ ЧИСЛО СТРОК В ТАБЛИЦЕ ЗАЯВОК
IF N>0 ' ЕСЛИ ТАМ ЧТО-ТО ЕСТЬ, ТО
FOR I FROM 0 TO NKILL
IF (GET_VALUE (GET_ITEM («ORDERS», I), «STATUS»)=«ACTIVE»… то смотрим сколько лотов осталось и решаем что с этим делать. в интернете полно примеров готовых роботов и блоков
Спасибо.
Этот параметр служебный на скорость исполнения не влияет. На квике можно делать ХФТ, там нет ограничений, проблема тока в интернете и кривых руках(кто любит в циклы задержки добавлять)
C# не знаю и знать не хочу :)
> C# не знаю и знать не хочу
Стратегическая ошибка. Все придется переписывать заново, если надо будет менять платформу.
Но, с одной стороны, менять вроде бы нет необходимости, а с другой — я отлично знаю другие языки и посему изучать .Net C#-клинопись необходимости не вижу.
Выбрал купайл только потому что хочу уменьшить количество прослоек между роботом и торговлей, что принесет большее моральное спокойствие. :)
я меньше делал — оно не ругалось… а в эктрим как-то не посчастливилось попадать
раздела «алгоритмический язык»
www.quik.ru/depot/chm_quik.zip
А выполнение этой функции, я так понимаю, приостанавливает скрипт до получения ответа от сервера, так?
пред посл. (вопрос): возможны — лично видал задупливания… но там не через скрипты выставлял а через импорт но на купайле — а на купайле можно контролировать это
первый ответ про нарушения очередности заявок/сделок? Если так, то про разные площадки — логично, про один инструмент — спасибо.
второй ответ — про рассогласования таблиц? А в каких местах «задупливания» были?
отправляем заявку
если она не встала отправлем еще раз
// тут первая строчка уже вставила ордер, и вторая вставила
опс! две заявки стоят…
но это решабельно, хотя на времени сказывается
Проверить, правильно ли что-то отображается, сверив в нескольких местах.
Вопрос в том, где на данный момент что правильно посчитано.
… а 2-3 сек задержки — это у вас на что было? почему?
Кароч система простая:
обычно робот обновляется 1/2 секунды (редко но бывает 3 секунды)
смотри таблицу выставленых заЯВок, запоминай номер, и смотри — если номер заявки исполнен полностью, тогда обновляй баланс (я его вообще отдельно от брокера считаю и храню — так то оно безопаснее, просто я его сравниваю иногда с официальными данными но не принимаю решения основываясь только на них)
Я так понимаю ты хочешь отправлять сразу же 3 заявки… я не буду отвечать тебе на вопрос, но спрошу — а зачем? И есть ли в этом алгоритм?
Если тут есть алгоритм, например заявка 1 исполнилась — баланс равен 1 контракт, цена снизилась на 1% купили еще 2 контракта (отправили заявку, исполнилась, обновили баланс), теперь у нас есть новая средняя величина по балансу, цена уже от обновленной средней цены снизилась на 1% и мы купили еще 3 контракта (заявка, исполнилась, обновили баланс).
Суть я думаю ты уловил. Возможно стоит делать все поступательно а не сразу пул заявок контролировать — ибо это сложнее
Если брать описанную ситуацию, как пример, то в случае когда цена спайканула, ордера исполнены, но позиция еще не изменилась, и робот по логике должен закрыться, он может начать пытаться вместо закрытия позиции выставлять новые ордера, на которые будет не хватать ГО… или наоборот откроет, а потом узнает, что позиция совсем не такая как надо и начнет чудить.
Что-то вроде этой ситуации предусмотреть можно, но могут быть и какие-то другие косяки.
Поэтому хочется определиться с тем, как лучше сделать, чтобы было как можно меньше проблемных мест. Тем более что с Купайлом у меня пока нет опыта косяков.
Ну как следствие не вижу причин далее смотреть проблему, так как на этом этапе она вроже как решилась.
Вопрос: как система принимает решение на открытие новой позиции? Думаю если тут логика чОткая то все нормально будет
«как система принимает решение на открытие новой позиции?» — в файле написано открыть — открывает. ЧОтче некуда! =)
… ну образно ;)
Если робот будет убыточным — обязательно расскажу всю схему! ))))