Блог им. SHLAK

Продолжение Средневзвешенная цена фьючерса,контроль набора позиций в QUIK

Вчера написал скрипт на LUA
Вычисление средней для Фьюча. 
но как обычно прежде чем доверить ему боевой режим крези тест.
Который не смог пройти.
Как это работает. Колбек OnTrade складывал value. BUY как есть,
Sell наделял "-"  
После делил на количество лотов. И всё работало.
А да, там приходит по три пакета, поставил фильтр что бы одни и те же trade_num (Номер сделки в торговой системе)не учитывались

В общем если торгую одним лотом всё гуд. Но стоит кинуть большим лотом. Или делать много сделок подряд. Беда
Такое ощущение что колбеки не приходят. Простейший парсинг и сложение value не работает. 
Что делаю не так? На форуме квика смешали всё в кучу. OnTransReply,  OnTrade, OnOrder.
Тут одно не пашет OnTrade. А там проверки перепроверки устроили говно скрипты не рабочие. ОНО ТУПО НЕ ПАШЕТ, какие блядь проверки. Когда не приходят кол беки с 2015 года ваши темы, и не одна не рабочая. Рассинхрон полный. В общем ХЕЛП

И ещё, после того как сработал колбек OnTrade, в его теле вызываю функцию в которой происходит пересчет текущей позы.
И что вы думаете, сделка исполнена, а поза прежняя. И только спустя какое то время срабатывает правильный пересчет
Он происходит из кол бека OnFuturesClientHolding (Функция вызывается терминалом QUIK при изменении позиции по срочному рынку)
Разрыв в пределах секунды. Вот такой тормоз!!!!!!!!
ХЕЛП по первому пункту. почему пропускаются кол беки?
Готов их дождаться, только они не приходят, не с задержкой не без неё. 
И зря вы думаете что ШАРПЫ, АЛАБЫ в целом вся эта глючная шляпа кого та спасет. Там это всё работает через эту же прослойку!
И только добавит новых глюков.  Удачных глючных трейдов!



  • обсудить на форуме:
  • Quik Lua
★4
17 комментариев
Квик для оперативных задач не годится.
Да и никто не годится.
Если, например, дальнейшие действия зависят от текущей позиции и эти дальнейшие действия наступают почти мгновенно, то нельзя полагаться на значения позиций, возвращаемых брокером через квик, эти значения надо вести самому виртуально. Параллельно вести потоки по контролю и сверке, но в моменте нужно оценивать всё логически. Квик никак не успеет. Как раз на уровне 1-2 секунды будут задержки… Я это в квике проходил, когда сетки заявок по стакану расставлял… если полагаться на квик, то система в разнос может уйти…
avatar
Sergey Pavlov, кол беки исполненных сделок становятся в очередь, какой блядь разнос? Откройте таблицу сделок, где там разнос? Мы сейчас говорим не о скорости, а о том что кол беки тупа пропадают.
Сделка исполнилась, сработал кол бек. Так вот не работает, не с задержками, не без них. Пакеты тупа пропадают, или пропускаются  
avatar
Борис Литвинов, всё зависит от логики и скоростей. Например, я кидаю заявку, которая изменяет мою позицию. Заявка уже сейчас исполнилась, реально позиция исполнилась. Мне уже при новой позиции надо делать другое действие, но, если я запрашиваю позицию у квика, то пока еще вижу старую позицию и пока еще не должен делать другое действие. Если я подожду, то увижу новую позицию, но уже рынок будет другой и уже поздно делать действие. Плюс при определенных нагрузках могут данные пропадать — это тоже возможно. Итого для критичных по быстродействию реагирования это всё не подходит изначально. Таковы условия. Поэтому коллокация и ДМА, где продублированы разные потоки.
avatar
Sergey Pavlov, так там и так прилетает по три дубля на один кол бек. И пропускает полностью некоторые из них. 
И какое отношение к исполненной сделки, ваши нагрузки?
Вы же сделку отменить, изменить не можете? нет! 
ГДЕ ОТ НЕЁ КОЛ БЕК?
avatar
Борис Литвинов, есть там глюк, в квике, как раз из этой области о которой вы пишите, не приходит ответ… разрабочики ТСЛаб боролись с этим и дергали разработчиков Квика, но не смогли… Если работаешь через Связку КвикЛуа тслабную, то в любой момент может сделки задваиваться, не срабаватыть и тд. Что то смпотоками там намудрили… Глюк действующий и не победимый Пока. Достаточно немного тормознуть квику, компу и теряется TransId
avatar
Вчера ещё у меня был косяк (скорее биржи). При открытии второй сделки, после завершенной первой, цена позиции левая.
Например открыл лонг Сбера по 22550, в таблице позиций и состояния счета — 22590. Закрыл на 22650, цена в этих таблицах 22580.
Причем в сделках все правильно и маржа верная. А цена — от балды.
У меня не было такого, чтобы не приходили коллбеки, а вот задваивались часто, контролировал сверкой неисполненного остатка по заявке.
1. Впервые слышу про то, что колбэки в очередь встают. На сколько мне известно — такого никогда не было. Если Вы выполняете вычисления непосредственно внутри функции OnTrade, и не успели их завершить до прихода следующего колбэка, то пришедший колбэк теряется.
2. Один из вариантов — вывести расчеты за пределы OnTrade, но помогает это не всегда.
3. Еще один вариант — обрабатывать только третий колбэк (тоже иногда бывают сбои)
4. Вообще, из-за чехарды с колбэками в квике я отказался от использования их по прямому назначению, и по сути обработка сводится с начала к проверке статуса заявки, и лишь после того как заявка стала неактивна, лезу в таблицу сделок для вычислений.
5. Для меня есть два состояния расчета цены и объема позиции:
1) размер позы и ее средняя цена до выставления заявки
2) размер позы и ее средняя цена после завершения работы с заявкой
Вся эта информация всегда хранится отдельно (в памяти робота + в файле)
6. На самом деле, после того как я перешел на C#, то несколько усложнил систему и вообще храню таблицы заявок и сделок вне квика, обновляя их по тем самым колбэкам, но при этом сохраняю возможность запросить данные напрямую в квике, на случай возникновения аномалий.
avatar
Prophetic, всё это прекрасно, не хочу сейчас даже развивать на сколько это грузит систему. У меня задача самое короткое получение средней. Без БД и всей этой балалайки. Тупа, средняя безубыточная из квика. По поводу очереди, думаю вы правы, её нет.
avatar
Борис Литвинов, Если хотите действительно простое и надежное решение — откажитесь от расчета по колбэку и переходите к периодическому опросу таблиц, по схеме которую я описал. У меня пару лет такая схема без сбоев работала, когда на QLua роботы были.
avatar
Prophetic, простите за резкость, но вы написали полную ерунду. Никакие колбеки не теряются.
avatar
swerg, А Вы, надо полагать, признанный эксперт в этом вопросе? Тогда просветите меня, как мне получить данные из колбэка пришедшого например 2 секунды назад, но необработанного программой в момент его поступления, из-за существенной задержки в цикле расчета данных, по предыдущему такому же колбэку.
Можно на простом примере обработки колбэка OnAllTrade.
avatar
Prophetic, Я вас не понимаю. Тык был вызов call-back функции или нет? Изначально вы писали о том, что call-back вовсе не был вызван. Теперь вроде как был, но вызов произошел раньше чего-то там? (!!) Это как?
Просьба изъясняться более понятно, с более развёрнутой фактической информацией, а не эмоциями.
avatar
swerg, Во-первых: Не стоит общаться с незнакомыми Вам людьми в требовательной форме. Ту Вам никто ничего не должен; во-вторых: Свой первоначальный ответ я писал не Вам, а автору топика, и он меня понял; в-третьих: Вы просто не пытаетесь вникнуть и разобраться в ситуации, но при этом яро критикуете мой опыт, даже не потрудившись проверить.
Напишу в последний раз:
Если решили обрабатывать какой-либо колбэк, то Вам необходимо обеспечить завершение выполнения всех функций, вызываемых в процессе обработки такого колбэка, ДО поступления следующего колбэка того же типа. Если программа не успевает этого сделать, то следующий пришедший колбэк «улетает в пустоту», т.к. Вы работаете в однопоточной среде, что равносильно отсутствию его вызова. По сути, Вы даже не узнаете, сколько каких колбэков Вы пропустили.
avatar
Prophetic, где вы увидели требовательную форму — я и не знаю. Всего лишь просьба, перечитайте.
Про потерю колбеков — в самом деле что-то странное. Быть может тут зависит всё же еще и от конкретного колбека? Вы упоминали OnAllTrade, быть может именно с ним есть какая-то хитрая особенность?
Понимаете, если бы колбеки в самом деле терялись бы — про это давно бы уже стоял вой на форуме квика. Но этого нет да и не было никогда. (Или я невнимательно читаю?).
Потому пока я всё же больше склоняюсь к какому-то не совсем правильному эксперименту с вашей стороны. Разумеется, могу ошибаться. Было бы очень интересно, если бы вы привели пример тестового скрипта (самого простого, не надо реальный торговый алгоритм), на котором вы обнаруживалась указанная вами проблема.
avatar
swerg, Я на Lua уже несколько лет практически ничего не пишу, после того как перешел на C#. И сейчас нет желания этим заниматься.
OnAllTrade взят как наиболее наглядный пример. То же самое возможно и с OnParam
Если у Вас есть два одновременно работающих терминала — сможете сами проверить. В одном сделайте скрипт, в котором в период какого-нибудь времени (например с 11:00 до 11:10) в функции OnAllTrade выводится/логируется номер сделки, и следом идет команда Sleep(500)
В другом нужно сделать все то же самое, но без команды Sleep.
А потом просто сравните, какого количества сделок Вы недосчитаетесь в первом логе.
Хотя, нафига проверять элементарные закономерности работы однопоточных  программ, я не знаю.
avatar

В общем решил задачу, как часы на любых скоростях.
Без бороды истории сделок, заявок, БД. 
Всё решил! Всем спасибо за дискуссию.  
avatar
Boris Litvinov, поделиться результатами и описанием в чем  была проблема как благодарность за дискуссию — желания нет?
avatar

теги блога Boris Litvinov

....все тэги



UPDONW
Новый дизайн