странный update quik

Страницы: 1
RSS
странный update quik, onTrade 3-6 раз
 
Добрый день

Сегодня согласился обновить файлы в Quik, получил проблемы с роботом.
Суть: ранее OnTrade вызывался только один раз, а теперь по 3-6 раз. Ранее многочисленные вызовы колбэк-функций наблюдал только в OnOrder.
Кроме того, дважды сегодня Quik самопроизвольно упал, чего раньше не наблюдалось. Может, просто совпадение...
Текущая версия 7.2.1.5.

Не вполне понятно, что делать c множественными вызовами OnTrade. Допустим, в заявке был указан объем 2. Из этого объема прошла сделка объемом 1. Потом пришел новый колбэк OnTrade с объемом 1 и тем же идентификатором заявки. Как понять, это повторное срабатывание OnTrade на первую половину или до конца уже исполнилась заявка, т.е. вторая половина пришла?

Кто-то еще поимел подобные проблемы... и проблемы ли это вообще? :)

Спасибо!
 
Вообще, колбэки не сама биржа шлёт? Я не уверен, апдейт Quik имеет какое-нибудь отношение к многочисленным срабатываниям OnTrade?
 
Здравствуйте,
Цитата
Сергей написал:
Кто-то еще поимел подобные проблемы... и проблемы ли это вообще? :)
Биржа ничего не знает про некоторые параметры сделок которые есть в QUIK
Например она ничего не знает про UID или про TRANS_ID
Эти параметры проставляются на сделке сервером QUIK. В результате могут произойти обновления параметров.

Вопрос уже неоднократно обсуждался на нашем форуме, например тут:
https://forum.quik.ru/messages/forum10/message12154/topic1301/

Цитата
Сергей написал:
Вообще, колбэки не сама биржа шлёт? Я не уверен, апдейт Quik имеет какое-нибудь отношение к многочисленным срабатываниям OnTrade?
Колбэки шлет сервер, но они появляются не просто так, а когда поступает информация с биржи.
 
Сергей, а изменения-то где и с чем они связаны? Робот у меня работает всего два месяца, все это время приходило по одному OnTrade на одну фактическую сделку. Это было удобно. Что и почему изменилось сейчас... и как теперь отличать новые и повторные OnTrade с одинаковыми идентификаторами?
 
Цитата
Сергей написал:
Сергей, а изменения-то где и с чем они связаны? Робот у меня работает всего два месяца, все это время приходило по одному OnTrade на одну фактическую сделку. Это было удобно. Что и почему изменилось сейчас...
Изменения в сервере, но поддержаны они в терминале.
Связаны с тем что у сервера появилась возможность указывать на сделках параметры которых нет на бирже.
Цитата
Сергей написал:
и как теперь отличать новые и повторные OnTrade с одинаковыми идентификаторами?
По ссылке которая была приведена выше, было предложено решение в виде запоминания номера сделки.
 
Сергей, предложенное решение выглядит очень рискованным. У меня парный трейдинг. Заявки по инструментам А и B выставляются одновременно. Конкретный сегодняшний пример. По инструменту А заявка была исполнена за две сделки А1 и А2, причем, по первой OnTrade сработал 6 раз, по второй 3 раза и по другому инструменту тоже 3 раза, и все это было жутко перемешано:

A1
A1
A1
A1
A2
A1
A1
A2
B
A2
B
B

Если бы объем по А1 и А2 был одинковым, их бы вообще не отличить... Мне как сравнение с номером последней сделки помочь может и как часто обновляется эта таблица сделок?
Все это нужно для быстрого расчета текущей позиции, которую вообще-то можно и в getItem("FUTURES_CLIENT_HOLDING",i).totalnet посмотреть... только эта таблица обновляется жутко редко. Наверно, где-то в настройках можно это время уменьшить, но все равно... За время между обновлениями можно так наторговать, что торговать будет нечем :) И каков вообще практический смысл от этих колбэк фукнций, если собственную позицию приходится определять вот так криво через анализ таблиц?

Не припомните ли вы обсуждение какого-либо более быстрого и надежного способа?

Спасибо!
 
Цитата
Сергей написал:
предложенное решение выглядит очень рискованным

Можете придумать другой вариант, например запоминать сделки в Lua таблице
Код
function OnTrade(trade) 

if not [trade.trade_num] then
[trade.trade_num]=true
...
end

end


Цитата
Сергей написал:
По инструменту А заявка была исполнена за две сделки А1 и А2, причем, по первой OnTrade сработал 6 раз, по второй 3 раза и по другому инструменту тоже 3 раза, и все это было жутко перемешано:
Так не должно быть (если говорить о боевом доступе)
должно быть максимум два, редко три колбека.
Но смотреть нужно со стороны брокера.

Цитата
Сергей написал:
getItem("FUTURES_CLIENT_HOLDING",i).totalnet посмотреть... только эта таблица обновляется жутко редко. Наверно, где-то в настройках можно это время уменьшить, но все равно.
В настройках терминала это не управляется.
С данным вопросом необходимо обратиться к брокеру.

Цитата
Сергей написал:
Не припомните ли вы обсуждение какого-либо более быстрого и надежного способа?
У Вас свои критерии, если для Вас сделки надежнее биржевых таблиц, значит смотрите сделки.
 
Эээээ... блин... а чего-то это их не отличить?! trade_num же есть... )))))
Извините, редко программлю, не все помню )
Большое спасибо!
 
я тоже столкнулся в роботе с дубликацией колбека на ontrade. но т.к. робота пишу недавно, то решил, что это мой глюк, и так всегда было, и это я просто заметил недавно. К тому же он у меня просто запускает некую процедуру, которая и так работает 1 раз в секунду, поэтому сильно задвоение не мешало.
Но как-бы все равно не кравиво, что колбек работает криво.

Я решил проблему запоминанием всех сделок в текстовую переменную через пробел.
А затем при повторном запуске проверкой, есть такой номер в этой строке или еще нет

Но хотелось бы от разработчиков услышать ответ!
 
Повторное срабатывание колбеков - явление нормальное... OnOrder у меня и раньше многократно срабатывали, никак не мешали, а OnTrade стал многократно срабатывать только на днях.

Я не стал запоминать Id сделок в таблице, в тектовую переменную пихать и т.п. Можно все проще сделать:
Цитата
LastTrade = 0
...
function OnTrade(trade)
       if LastTrade >= trade.trade_num then return end
       [здесь тело обработки вызова]
       LastTrade = trade.trade_num
end

Идентификаторы сделок увеличиваются. Это порядковый номер сделки на сервере. То есть, обрабатывать нужно только те вызовы, где идентификатор больше ранее приходивших.
 
Цитата
Sergey Denegin написал:
Но хотелось бы от разработчиков услышать ответ!
Таблица сделок является обновляемой.
При установке дополнительных параметров на сделке, приходит повторный колбек.
 
Sergey Gorokhov,
1. есть ли вероятность, что колбек с меньшим trade.trade_num впервые придет позже, чем колбек с каким-то бОльшим trade.trade_num?
2. у меня реально приходят по 6 вызовов иногда. Торгую через Промсвязьбанк. Что за параметры можно в сделке менять и дополнять по шесть раз?
 
Цитата
Сергей написал:
1. есть ли вероятность, что колбек с меньшим trade.trade_num впервые придет позже, чем колбек с каким-то бОльшим trade.trade_num?
Да если сделки из разных классов
Цитата
Сергей написал:
2. у меня реально приходят по 6 вызовов иногда. Торгую через Промсвязьбанк. Что за параметры можно в сделке менять и дополнять по шесть раз?

Нужна конкретика и пример кода. Должно быть 2-3 колбека.
 
1. то есть, внутри одного класса "SPBFUT" нет такой вероятности? Указанная выше проверка надежна?
2.
Код
function OnTrade(trade)
...
        myLog('OnTrade:  qty='..trade.qty.." Order="..trade.order_num.." Trade="..trade.trade_num..' Value='..trade.value)
end
...и потом наблюдаю их в логе по 6 штук (редко), обычно по 3
 
Цитата
Сергей написал:
1. то есть, внутри одного класса "SPBFUT" нет такой вероятности? Указанная выше проверка надежна?
В рамках одного класса такого быть не должно.
Что касается надежности то для ответа на вопрос нужны тесты.

Цитата
Сергей написал:
...и потом наблюдаю их в логе по 6 штук (редко), обычно по 3
Нужен конкретный пример Дата/время/номера.
 
05/23/16 15:54:22  Order=21375094379
Таких пришло 6 штук. Подозреваю, все же это были две серии с разными trade_num. Позавчера я еще тупил с возможностью различать такие сделки :) Свежих нет.
 
Цитата
Сергей написал:
05/23/16 15:54:22  Order=21375094379
Таких пришло 6 штук. Подозреваю, все же это были две серии с разными trade_num. Позавчера я еще тупил с возможностью различать такие сделки :) Свежих нет.

Если будет пример лога с одинаковым trade_num мы рассмотрим эту проблему
Так как сейчас нет уверенности в наличии шести колбеков по одной сделке, то вопрос считаем закрытым.
Следует отметить что ранее от других пользователей подобных обращений не было, то есть вероятность ошибочного вывода крайне высока.

Как уже было сказано, для сделок допустимо не более 3х колбеков.
и то наличие 3го колбека мы признали ошибкой в ПО, которая пока еще не исправлена.
 
Специально сделал только что выгрузку целой таблицы trade из функции Ontrade при совершении одной сделки. Как и писалось выше, на одну сделку Ontrade срабатывает 3 раза. И все три раза записи абсолютно одинаковые, о чем говорит лог.
Зачем это? Ранее писалось, что они чем-то должны отличаться

{["price"]=90560,["settle_date"]=20160526,["trade_num"]=1494737925,["lower_discount"]=0,["exchange_comission"]=2,["value"]=119121.9,["qty"]=1,["reporate"]=0,["clearing_bank_accid"]="",["class_code"]="SPBFUT",["userid"]="fg76rm_finam00",["tradenum"]=1494737925,["flags"]=32, ["canceled_datetime"]={["week_day"]=1,["hour"]=0,["ms"]=0,["mcs"]=0,["day"]=1,["month"]=1,["sec"]=0,["year"]=1601,["min"]=0,}, ["clearing_firmid"]="",["kind"]=1, ["datetime"]={["week_day"]=3,["hour"]=20,["ms"]=76,["mcs"]=76000,["day"]=25,["month"]=5,["sec"]=1,["year"]=2016,["min"]=1,}, ["ordernum"]=21416512626,["sec_code"]="RIM6",["system_ref"]="",["block_securities"]=0,["repoterm"]=0,["broker_comission"]=0,["period"]=1,["client_code"]="7618frn",["linked_trade"]=0,["firmid"]="SPBFUT",["account"]="7618frn",["yield"]=0,["seccode"]="RIM6",["trans_id"]=1,["upper_discount"]=0,["repo2value"]=0,["start_discount"]=0,["tech_center_comission"]=0,["trade_currency"]="SUR",["accrued2"]=0,["order_num"]=21416512626,["repovalue"]=0,["exchange_code"]="",["accruedint"]=0,["settle_currency"]="",["cpfirmid"]="",["uid"]=159231,["brokerref"]="7618frn",["station_id"]="",["price2"]=0,["clearing_comission"]=0,["settlecode"]="T1",["bank_acc_id"]="",}

{["price"]=90560,["settle_date"]=20160526,["trade_num"]=1494737925,["lower_discount"]=0,["exchange_comission"]=2,["value"]=119121.9,["qty"]=1,["reporate"]=0,["clearing_bank_accid"]="",["class_code"]="SPBFUT",["userid"]="fg76rm_finam00",["tradenum"]=1494737925,["flags"]=32, ["canceled_datetime"]={["week_day"]=1,["hour"]=0,["ms"]=0,["mcs"]=0,["day"]=1,["month"]=1,["sec"]=0,["year"]=1601,["min"]=0,}, ["clearing_firmid"]="",["kind"]=1, ["datetime"]={["week_day"]=3,["hour"]=20,["ms"]=76,["mcs"]=76000,["day"]=25,["month"]=5,["sec"]=1,["year"]=2016,["min"]=1,}, ["ordernum"]=21416512626,["sec_code"]="RIM6",["system_ref"]="",["block_securities"]=0,["repoterm"]=0,["broker_comission"]=0,["period"]=1,["client_code"]="7618frn",["linked_trade"]=0,["firmid"]="SPBFUT",["account"]="7618frn",["yield"]=0,["seccode"]="RIM6",["trans_id"]=1,["upper_discount"]=0,["repo2value"]=0,["start_discount"]=0,["tech_center_comission"]=0,["trade_currency"]="SUR",["accrued2"]=0,["order_num"]=21416512626,["repovalue"]=0,["exchange_code"]="",["accruedint"]=0,["settle_currency"]="",["cpfirmid"]="",["uid"]=159231,["brokerref"]="7618frn",["station_id"]="",["price2"]=0,["clearing_comission"]=0,["settlecode"]="T1",["bank_acc_id"]="",}

{["price"]=90560,["settle_date"]=20160526,["trade_num"]=1494737925,["lower_discount"]=0,["exchange_comission"]=2,["value"]=119121.9,["qty"]=1,["reporate"]=0,["clearing_bank_accid"]="",["class_code"]="SPBFUT",["userid"]="fg76rm_finam00",["tradenum"]=1494737925,["flags"]=32, ["canceled_datetime"]={["week_day"]=1,["hour"]=0,["ms"]=0,["mcs"]=0,["day"]=1,["month"]=1,["sec"]=0,["year"]=1601,["min"]=0,}, ["clearing_firmid"]="",["kind"]=1, ["datetime"]={["week_day"]=3,["hour"]=20,["ms"]=76,["mcs"]=76000,["day"]=25,["month"]=5,["sec"]=1,["year"]=2016,["min"]=1,}, ["ordernum"]=21416512626,["sec_code"]="RIM6",["system_ref"]="",["block_securities"]=0,["repoterm"]=0,["broker_comission"]=0,["period"]=1,["client_code"]="7618frn",["linked_trade"]=0,["firmid"]="SPBFUT",["account"]="7618frn",["yield"]=0,["seccode"]="RIM6",["trans_id"]=1,["upper_discount"]=0,["repo2value"]=0,["start_discount"]=0,["tech_center_comission"]=0,["trade_currency"]="SUR",["accrued2"]=0,["order_num"]=21416512626,["repovalue"]=0,["exchange_code"]="",["accruedint"]=0,["settle_currency"]="",["cpfirmid"]="",["uid"]=159231,["brokerref"]="7618frn",["station_id"]="",["price2"]=0,["clearing_comission"]=0,["settlecode"]="T1",["bank_acc_id"]="",}
 
Цитата
Sergey Denegin написал:
Зачем это? Ранее писалось, что они чем-то должны отличаться

Как уже было сказано, для сделок допустимо не более 3х колбеков.
и то наличие 3го колбека мы признали ошибкой в ПО, которая пока еще не исправлена.
 
Поясните пожалуйста смысл этой фразы про "допустимое количество колбеков".
Не совсем понятно, ведь суть колбека в том, что он срабатывает только при обновлении чего-нибудь, и логично, что это должно быть один раз на каждое изменение без пропусков и задвоений. Иначе весь смысл теряется, если каждый раз еще нужно проверять, а не дубликат ли это
 
В первую очередь волнует вопрос - теперь во всех колбеках можно ожидать неоднократного срабатывания на одно и тоже событие?  
 
Sergey Denegin, почитайте эту тему: https://forum.quik.ru/forum10/topic1082/
Некоторые моменты уже объяснялись.
Lbot3D
 
Ну и флейм там Старатель развел... Но именно благодаря ему многое стало понятно "очень" :)
Старателю, наверно, стоило бы свой собственный терминал написать, чем так с поддержкой рубиться :)
Столько нервов потрачено с обеих сторон... Нерентабельная битва :)
Страницы: 1
Читают тему
Наверх