SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
Блог им. akaRem
Вопрос о стандартных задержках в обновлении данных QUIK/QPILE
- 15 ноября 2012, 09:12
- |
Хочу написать торгового робота на языке 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) лимиты по деньгам и бумагам (для фьючерсов позиции и ограничения).
(Не ХФТ, но нужно четко контролировать позиции по инструментам, активные и исполненные заявки, а так же совершенные сделки с наименьшими «тормозами»)
Подскажите, пожалуйста, какие задержки являются нормальными (понятно, что они всегда есть, интересуют их «обычные» величины — от… до… )
— между двумя последовательными итерациями скрипта (и что будет, если его зациклить на постоянный пересчет?) (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) лимиты по деньгам и бумагам (для фьючерсов позиции и ограничения).
243 |
Читайте на SMART-LAB:
Tickmill и TradingView: профессиональный анализ становится бесплатным
Трейдеры часто сталкиваются с дилеммой: либо платить за качественные инструменты анализа, либо довольствоваться урезанными бесплатными...
13:47
От лаборатории до рудника: как инновации дают $100 млн эффекта
Новые разработки — один из важных драйверов развития «Норникеля». Сегодня совокупная годовая экономическая отдача от внедренных решений превышает...
09:08
теги блога akaRem
- ARCA
- Arche
- BATS
- ECN
- fee
- Hot Key
- MICEX
- NASDAQ
- NYSE
- qpile
- QScalp
- quik
- rebate
- RTS
- RuTicker.com
- SnP
- www.tradingview.com
- американские акции
- брокеры
- вопросы
- грааль
- график
- кукл
- лента
- ОИ
- опрос
- РИ
- робот
- РТС
- рынок
- сбер
- скальперский привод
- скальпинг
- торговые роботы
- торговый привод
- трейлинг стоп
- халява
Основное, что интересует: на какую производительность реально имеет смысл рассчитывать алгоритмы и коэффициенты, и какие дынные стоит перепроверять (мало ли что там в квике возможно) — отсюда растут ноги точности приказов, ММ, и доходности с одной стороны; и сложности алгоритмов — с другой.
А как ты (можно на ты?) отслеживаешь тек. позицию и заявки?
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 контракта (заявка, исполнилась, обновили баланс).
Суть я думаю ты уловил. Возможно стоит делать все поступательно а не сразу пул заявок контролировать — ибо это сложнее
Если брать описанную ситуацию, как пример, то в случае когда цена спайканула, ордера исполнены, но позиция еще не изменилась, и робот по логике должен закрыться, он может начать пытаться вместо закрытия позиции выставлять новые ордера, на которые будет не хватать ГО… или наоборот откроет, а потом узнает, что позиция совсем не такая как надо и начнет чудить.
Что-то вроде этой ситуации предусмотреть можно, но могут быть и какие-то другие косяки.
Поэтому хочется определиться с тем, как лучше сделать, чтобы было как можно меньше проблемных мест. Тем более что с Купайлом у меня пока нет опыта косяков.
Ну как следствие не вижу причин далее смотреть проблему, так как на этом этапе она вроже как решилась.
Вопрос: как система принимает решение на открытие новой позиции? Думаю если тут логика чОткая то все нормально будет
«как система принимает решение на открытие новой позиции?» — в файле написано открыть — открывает. ЧОтче некуда! =)
… ну образно ;)
Если робот будет убыточным — обязательно расскажу всю схему! ))))