Сергей (Все сообщения пользователя)

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1
Поле "Позиция" в доске опционов, Баг
 
Все таки хотелось бы подробнее узнать насчет фикса "В таблице «Доска опционов» неверно отображалась своя позиция.".
У ваших разработчиков ведь есть трекинг система и есть тикет по этому  поводу. Хотелось бы узнать детали.
Медленный getItem для таблицы depo_limits, Работает медленно на последних версиях
 
Цитата
Павел Bosco написал:
сегодня брокер обновил до 27 версии
у меня в таблице всего 8 строк, так что я поставил ccc=100000
результат такой
total_limits=800000 total_time_ms=67875 avg_ms=0.084844

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

но у меня проблема как видите не воспроизвелась.
тестировал сейчас на подключенном к серверу терминале.
Спасибо что попробовали у себя. У вас тоже все нормально. Пока причина почему у меня не работает, непонятна. Я специально останавливал все другие скрипты во время теста. Кстати аналогичные действия с таблицей "futures_client_holding" на новой версии у меня отрабатывают корректно.
Поле "Позиция" в доске опционов, Баг
 
Egor Zaytsev написал:
Цитата
Цитата
Сергей написал:
Ситуация не воспроизвелась, однако вы пофиксили проблему в версии 7.19 с описанием "В таблице «Доска опционов» неверно отображалась своя позиция.". Хотелось бы объяснений, почему на мой запрос адекватного ответа не было, но проблема существовала.
Добрый день.
Вы нам письмо писали по нашему запросу?

Если да, то просьба сообщить либо тему письма, либо вашу почту.
Кроме того, что я писал в этой теме, я больше никаких запросов не отправлял.
Медленный getItem для таблицы depo_limits, Работает медленно на последних версиях
 
Никакие другие программы тоже не могли повлиять (я про изменение интервала таймера), так как у меня запущены одни и те же программы, когда я тестирую с версией 19 и с версией 27.
Может сам QUIK что-то стал делать с интервалом в последних версиях?
Медленный getItem для таблицы depo_limits, Работает медленно на последних версиях
 
Сделал скрины









Все остальные скрипты во время тесты не были запущены, так что повлиять не могли.


Если вообще убрать вызов getItem из моего первого сообщения, естественно все быстро работает и не тормозит.
Мультимониторность, Есть шанс на такую фичу?
 
Цитата
Imersio Arrigo написал:
Цитата
Сергей написал:
запускалось сразу два окна QUIK'а, одно на первом мониторе, второе на втором.
Что мешает растянуть одно окно квика на два монитора? Тот же эффект.
Нет, это не тот же эффект.
Хотелось бы чтобы на первом мониторе было содержимое одной вкладки, а на втором - содержимое другой вкладки. Чтобы сразу могу обе видеть.
А если растянуть, то получится просто большая одна вкладка.
Медленный getItem для таблицы depo_limits, Работает медленно на последних версиях
 
Цитата
Sergey Gorokhov написал:
Сергей,
Вам наглядно было показано что у нас проблема не воспроизводится, а значит нам нужна дополнительная информация которую мы и пытаемся от Вас получить.
Вы, к сожалению, всеми силами отказываетесь нам эту информацию предоставить.
Если я предоставлю тот же самый скрин, когда отключен терминал, этого будет достаточно?
Просто у меня пока нет возможности, потому что приходится каждый раз обновлять версию и откатывать. Я могу дать такой скрин позже, если это действительно нужно. Но это 100% будет тоже самое, потому что я вчера воспроизводил такие тормоза именно в оффлайне.
Какая еще дополнительная информация нужна?
Медленный getItem для таблицы depo_limits, Работает медленно на последних версиях
 
Цитата
Sergey Gorokhov написал:
Сергей,
Повторите то же самое при отключенном терминале.
И не надо менять код тестового скрипт, это совершенно лишнее.
Что значит отключенном, какая разница отключен или нет? Я думаю это совершенно не зависит от того, подключен ли сервер или нет.

Разве вы не видите, сколько у меня времени занимает getItem и не видите, сколько у меня строк в таблице и у вас? Как я не могу менять код. Это совершенно необходимо чуть поменять код, чтобы было значимое количество итераций и у меня чтобы не занимала час работа скрипта. Я думаю вы в состоянии понять смысл моих минимальных правок в тестовом скрипте.

Я думаю из моих скринов совершенно все ясно, что апгрейд QUIK'а влияет на производительность getItem и действительно как-то связан со стандартным виндовым периодом таймера, так как у меня среднее время итерации 15,6 мс пополам.
Почему у вас такое отношения к багам от пользователей? Почему вы все время пытаетесь убедить, что программа ваша идельная , а пользователи тупые?

Разве вы не можете просто передать мою информацию (а по моему из работы тестового скрипта ее достаточно) разработчикам?
Медленный getItem для таблицы depo_limits, Работает медленно на последних версиях
 
Цитата
Sergey Gorokhov написал:

Если к нам нет доверия, Вы можете проверить данные самостоятельно:

 
Если ко мне нет доверия, вот мои скрины и код.








Медленный getItem для таблицы depo_limits, Работает медленно на последних версиях
 
Цитата
Сергей написал:
Цитата
Sergey Gorokhov написал:
Здравствуйте,
А если вообще убрать getItem из цикла?
Больше похоже на таймер Windows нем на проблему с QUIK
Про таймер рассказано например тут
 https://habr.com/ru/company/intel/blog/186998/  

и как можете заметить он тоже приблизительно равен 15 мс
Как я вынесу getItem из цикла? Мне нужно найти нужный инструмент из таблицы. Для этого нужно перебирать каждый элемент. Если это не QUIK, почему тогда на 19 версии все работает?
Кроме того, я никаких таймеров не взводил. Если это QUIK выполняет данный цикл через таймеры, то это значит что он неправильно работает.
Медленный getItem для таблицы depo_limits, Работает медленно на последних версиях
 
Цитата
Sergey Gorokhov написал:
Здравствуйте,
А если вообще убрать getItem из цикла?
Больше похоже на таймер Windows нем на проблему с QUIK
Про таймер рассказано например тут
https://habr.com/ru/company/intel/blog/186998/

и как можете заметить он тоже приблизительно равен 15 мс
Как я вынесу getItem из цикла? Мне нужно найти нужный инструмент из таблицы. Для этого нужно перебирать каждый элемент. Если это не QUIK, почему тогда на 19 версии все работает?
Мультимониторность, Есть шанс на такую фичу?
 
Цитата
Zoya Skvorcova написал:
Сергей, добрый день.
На данный момент за пределы основного окна можно выносить только таблицы. Мы можем зарегистрировать от Вас пожелание, что бы можно было выносить вкладки за пределы основного окна. Регистрируем?
Хотелось бы не просто вынос вкладки за пределы основного окна. Хотелось бы следующего: чтобы при соответствующей настройке (предположим два монитора), запускалось сразу два окна QUIK'а, одно на первом мониторе, второе на втором. И пользователь может хоть как переносить окна и вкладки между двумя окнами на каждом мониторе так, как будто это один монитор.
Мультимониторность, Есть шанс на такую фичу?
 
Здравствуйте!

Планируется ли ввести поддержку нескольких мониторов в QUIK. Хотелось бы одновременно видеть содержимое одной вкладки на первом мониторе, и второй вкладки - на втором мониторе.
Поле "Позиция" в доске опционов, Баг
 
Ситуация не воспроизвелась, однако вы пофиксили проблему в версии 7.19 с описанием "В таблице «Доска опционов» неверно отображалась своя позиция.". Хотелось бы объяснений, почему на мой запрос адекватного ответа не было, но проблема существовала.
Медленный getItem для таблицы depo_limits, Работает медленно на последних версиях
 
Скрипт на Lua,
Обычный обход item'ов таблицы "depo_limits".

Код
local items_num = getNumberOf("depo_limits")
for i = 0, items_num - 1 do
  local table_item = getItem("depo_limits", i)
  --дальнейшие действия с table_item
end 
Цикл работает чрезвычайно медленно, что приводит к тормозам моего скрипта. Всего кол-во строк в таблице (items_num) чуть более ста.
Трассировка говорит, что вызов getItem занимает 0,015 с. Можно посчитать, что каждый такой цикл занимает 1,5с.


Проявляется на новых версиях QUIK'а. Последняя версия QUIK где работает нормально - 7.19.3.1.

В связи с этим больше не обновляю QUIK.


Данный код просто лишь загружает в мою таблицу баланс по инструменту. Кол-во отслеживаемых инструментов более сотни, можете посчитать, сколько у меня занимает инциализация таблицы (1,5с x 100 = 150сек это в лучшем случае).

SearchItems работает аналогично для этой таблицы. Остальные таблицы кажется отрабатывают корректно, но проверял не все.

Изменяя копию таблицы, меняется оригинальная таблица., Особенность языка lua?
 
Цитата
Сергей написал:
Обнаружил неприятную (для себя) штуку. Нужно проанализировать как-то таблицу. В моем конкретном случае понадобилось выбросить несколько максимальных значений и найти среднее среди остальных.


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

Получается, когда я присваиваю массив, я фактически просто создаю ссылку на оригинальный массив. При обращении по любому имени редактируются одни и те же данные? Как создать фактическую копию таблицы? По элементам в цикле присваивать? :))
Смотрите документацию Lua

https://www.lua.org/manual/5.3/manual.html#3.3.3

Там сказано:

Цитата
Tables, functions, threads, and (full) userdata values are objects: variables do not actually contain these values, only references to them. Assignment, parameter passing, and function returns always manipulate references to such values; these operations do not imply any kind of copy.
Порядок отслеживания процесса выполнения транзакций
 
Мой небольшой опыт.
В своем роботе, когда фильтровал нужные ответы в onTransReply,
мне приходилось фильтровать также по полю time, типа такого
Код
function TradeItem:handleTransReply(trans_reply)
    ....
    if trans_reply.trans_id ~= self.trans_id or not trans_reply.time or trans_reply.time <= 0 then
        return
    end
    ....
end

Кроме того, при генерации trans_id, у меня в потоке всех заявок иногда случались одинаковые числа при использовании hh:mm:ss +  math.random(1, 999), что меня порядком удивило и приводило к багам, поэтому пришлось проверять дополнительно:

Код
function TradeItem:generateTransId()
    local resId
    repeat 
        resId = tonumber(utils.getNormalizedTime() .. string.format("%03d", math.random(1, 999)))
    until TradeItem.trans_ids[resId] == nil
    return resId
end


Есть конечно множество других ньюансов, но о всех и не вспомнишь. Вообще весь механизм OnTransReply -> OnTrade -> OnOrder в QUIK'е (или на бирже) баганутый. Довольно редко, но transReply иногда просто не приходит. Приходится придумывать всякие воркараунды.

Просто смысл в том, что одно дело - это написать код, который по идее должен работать согласно документации, а другое дело - заставить его работать абсолютно всегда, без всяких фокусов раз в день - при большом потоке заявок. Второе довольно сложно.
QLua и БД, QLua и БД
 
Продолжил работать над задачей описанной в начале темы. Поместил методы записи в базу в отдельную dll (таким образом почти полностью переписал функционал с lua на c++), к сожалению проблема осталось той же: QUIK падает через некоторое время работы. Зато теперь падает с дампом. Уважаемая тех. поддержка, куда мне нужно направить файл дампа, чтобы кто-нибудь мог посмотреть возможную причину? Так как pdb у меня нет, то символы из дампа я загрузить не могу, вижу только ошибку "Access violation reading location xxxx".
Поле "Позиция" в доске опционов, Баг
 
Цитата
Egor Zaytsev написал:
Цитата
Сергей   написал:
Вот скрин. Только по нему   видно, что показывает ерунду. Реальная позиция PUT = 8.


Добрый день.

Это скриншоты с одного терминала в одно время? Т.е вы открыли две таблицы и в них разные значение позиции?
Да, именно так.
Чтобы вопроизвести баг, необязательно открывать вторую такую же таблицу. Нужно просто перевыбрать инструмент в той же самой таблице - и значение в поле позиция обнулится.
Поле "Позиция" в доске опционов, Баг
 
Вот скрин. Только по нему   видно, что показывает ерунду. Реальная позиция PUT = 8.


Поле "Позиция" в доске опционов, Баг
 
Здравствуйте,


Начиная с версии 7.16, поле Позиция в доске опционов иногда показывает неправильное значение. Какой-то конкретной закономерности не заметил, но что-то точно не так. В версиях 7.14 и ранее это поле всегда показывало корректное значение.
QLua и БД, QLua и БД
 
Кажется, причина ясна.Дело оказалось вовсе не в БД, а в одновременном доступе к мапу из разных ниток.
В потоке main() делалось чтение из базы и загрузка данных из нее в глобальный мап типа { "SR" = {...}, "GZ" = {...}, "RI" = {} } (то есть таблица, где ключом является не индекс, а строки).
В функции обратного вызова делалось чтение из этого глобального мапа с использованием pairs(). Пока вторая нитка перебирала элементы, первая как раз в этот же момент изменила мап, и все упало.
Я конечно знаю про потокобезопасные функции table.sinsert и т.д., но они только для нумерованных таблиц.
Так что придется использовать что-то типа эмуляции критической секции, как описано здесь https://forum.quik.ru/forum10/topic3272/ или поменять структуру данных. Сделать все в один поток не получится, потому что скрипт сложный и большой и он не только занимается работой с базой.
QLua и БД, QLua и БД
 
Цитата
Suntor написал:
Первое утверждение противоречит второму. Косяк явно в коде работы с БД.
Не вполне пойму, в чем противоречие. У меня в скрипте довольно тонкая прослойка к упомянутым третьесторонним библиотекам - открываю соединение, получаю данные из QUIK'а о нужных инструментах, делаю вызов INSERT, как в примере https://keplerproject.github.io/luasql/examples.html. У LuaSQLite3 другой API и обращение к другой dll - и падение то же самое повторяется. Если бы в моем скрипте была бы ошибка, то не работало бы вообще.




Цитата
Suntor написал:
Попробуйте вынести весь свой скрипт в отдельный процесс через LuaRPC (найдите любую реализацию в сети, к примеру, есть готовая под QLua: quik-lua-rpc), и посмотрите, какой процесс у вас будет падать в итоге...
Не очень знаком с технологиями "Protocol Buffers", "ZeroMQ", которые тут указаны. Я так понял смысл в том, что мой скрипт будет запущен обычным интерпретатором Lua и будет RPC-клиентом. Для получения данных из QUIK он будет делать RPC вызовы на скрипт (RPC-сервер) запущенный в это время в QUIK'е. Я правильно понимаю? В итоге получается, что "вынести в отдельный процесс" означает по сути "переписать всю программу" на этих неизвестных мне технологиях. Думаю легче сделать по другому: написать dll, которая сама будет делать inset'ы в базу, а lua-скрипт из QUIK'а просто будет давать dll'ке нужные данные.
QLua и БД, QLua и БД
 
Есть проблема, с которой борюсь довольно давно, но к сожалению, так ее и не удалось решить, и похоже все дело именно в связке QUIK-QLua-Lua.
Я написал скрипт на Lua, который периодически записывает данные о параметрах опционов (волатильность и т.д.) в БД, чтобы в дальнейшем использовать данную информацию для сложных запросов. Для записи в БД пробовал пользоваться несколькими сторонними библиотеками: LuaSQL (https://keplerproject.github.io/luasql/) и LuaSQLite3 (http://lua.sqlite.org/index.cgi/index). При этом в случае LuaSQL пробовал реализацию для sqlite и mysql.
Сами библиотеки прикрутить к QUIK'у удалось, хотя это непросто. Но итоговый результат к сожалению печальный: скрипт работает определенное время, делает записи в БД, как надо, но потом QUIK просто падает (без дампа, без всего). Если записи в БД делать два раза в секунду, то падает через несколько минут. Если писать раз в минуту (как изначально мной предполагалось), то падает через полчаса, а может через пару часов. Мне нужна стабильная работа в течение всего дня. За одну итерацию пишу около сотен строк в БД, что полная ерунда для современных мощностей. Смотрел на использование ЦП QUIK'ом во время работы скрипта - все нормально. Пробовал запись как из потока main, так и из функций обратного вызова - результат один и тот же.
То, что один и тот же результат воспроизводится для различных библиотек и различных СУБД, говорит о том, что дело не в них, а в QUIK'е или QLua. Если записывать все нужные данные просто в файл csv, а не в БД, то все стабильно работает. По опыту могу сказать, что падение может быть вызвано ошибкой при одновременном доступе к одному участку памяти в QUIK'е или запил памяти, но так как у меня нет исходного кода ни qlua.dll, ни quik.exe, то я не могу ничего сказать и сделать. Неужели моя задача никак не решается с использованием QUIK? Хотелось бы получить ответ от разработчиков. Я могу дать код скрипта, если нужно. Пробовал на версиях QUIK 7.14 и 7.16.
Большие ли отличия QLua от от Lua и где официальная документация?, Какая версия Lua в QLua, работают ли все функции Lua или только какой-то ограниченный набор (если так, то где прочитать, какой?), можно ли подключать модули и все как в обычном Lua? Есть ли где-то на официальном сайте документация?
 
Здравствуйте!
Хотелось бы узнать точно, какая версия Lua используется в QLua. Я имею ввиду 5.1.4 или 5.1.5. Это важно при использовании сторонних библиотек в скриптах, так как постоянно проблемы с совместмостью.
Доходность облигаций - как получить по цене заявки?, Доходность облигаций - как получить по цене заявки?
 
Цитата
Egor Zaytsev написал:
Цитата
Сергей   написал:
Мне нужны данные расширенной таблицы котировок EXT_ORDERBOOK из     ftp://ftp.micex.ru/pub/ClientsAPI/ASTS/Bridge_Interfaces/Equities/Equities23­ ­   ­_Broker_Russian.htm  
Можно ли ее получить из скрипта Lua?
Добрый день.

Как уже ответил Сергей такой возможности в текущей реализации нет.
Готовы зарегистрировать пожелание.
Если это возможно, я бы хотел данное улучшение зарегистрировать.
SearchItems: утечки памяти
 
Многократные вызовы SearchItems для поиска нужного инструмента в таблице лимитов по бумагам приводят к утечкам памяти, которые не может устранить сборщик мусора Lua.

Следующий метод возвращает баланс по заданному инструменту и коду клиента:
Код
function TradeItem:get_balance()
   local res = 0
   if self.bal_func == nil then
      self.bal_func = function(t) return t.limit_kind == 2 and t.client_code == self.clientcode and t.sec_code == self.seccode end
   end
   local sec_table = SearchItems("depo_limits", 0, getNumberOf("depo_limits") - 1, self.bal_func)
   if sec_table and #sec_table > 0 then 
      local table_item = getItem("depo_limits", sec_table[1])
      if table_item then
         res = table_item.currentbal
      end
   end
   return res
end
Вызывается этот метод часто (несколько раз в секунду) и приводит к серьезным утечкам памяти (объем используемой памяти проверяю через функцию collectgarbage("count")). За день работы набирается больше 2 Гб.

Если я буду искать нужный инструмент просто прямым перебором всех строк в таблице, то все нормально.

Могут ли разработчики взглянуть на данную проблему? Версия QUIK 7.5.0.72, Lua версии 5.1.
Доходность облигаций - как получить по цене заявки?, Доходность облигаций - как получить по цене заявки?
 
Мне нужны данные расширенной таблицы котировок EXT_ORDERBOOK из ftp://ftp.micex.ru/pub/ClientsAPI/ASTS/Bridge_Interfaces/Equities/Equities23­_Broker_Russian.htm
Можно ли ее получить из скрипта Lua?
Доходность облигаций - как получить по цене заявки?, Доходность облигаций - как получить по цене заявки?
 
Как известно, информацию о котировках в стакане можно получить с помощью функции getQuoteLevel2.
Но она возвращает только цены и количество заявок.
В интерфейсе же QUIK, если в таблицу котировок добавить столбец "Доходность", доступна также информация о доходности облигации, вычисленной для каждой котировки в стакане. Как мне программно ее получить?
По сути нужна функция getYield(price), возвращающая для конкретной облигации доходность по цене заявки.
Страницы: 1
Наверх