Nikolay (Все сообщения пользователя)

Пока гарантированность не будет указана в документации, то все это спекуляции. Я, конечно, могу предположить, что если документация банально написана плохо, то многие моменты там не будут указаны.
Но тогда, необходимо хотя бы подтверждение от поддержки.

1: 99 мб
2: 28 мб
3: 60 мб

1-й самый медленный. Но он всегда был таким, даже когда ничего не было открыто.
В 1-ом и 3-ем есть поток данных по опционам.

Также заметил, что если скрипт стартует вместе с терминалом и при этом скрипт заказывает данные через ParamRequest, то все начинает очень тормозить. Если же скрипт запустить после того как время сервера от пакетов догонит текущее, то намного быстрее. Так что есть подозрение, что в 12-ой версии сломали работу заказа данных из разных потоков, они банально мешают друг-другу. Сейчас добавил принудительное ожидание LASTRECORDTIME прежде чем что-то заказывать. Но как бы сам факт запуска скриптов, т.е. создание отдельных потоков в процессе запуска после OnCleanUp не было причиной.

Так что в очередной раз новая версия заставляет заниматься бесполезной деятельностью.

Я не искал специально на форме, это было еще в 7-ой версии терминала. Т.к. после этих случаев я просто изменил подход, то и нет необходимости отслеживать. В данном случае - решение каждый принимает сам.
Данная дискуссия просто обсуждение подходов с учетом официальной информации доступной в документации.

Сегодня специально убрал все таблицы текущих торгов, особенно с иностранными акциями. Была, оказывается, открыта в свернутом виде. И терминал прямо ожил. Т.е. ТТТ с большим числом записей дает такую загрузку терминала.

Вы в документации видите утверждение о гарантированности доставки, вызова. А если нет, то значит это не ошибка, а особенность. В документации к RabbitMQ гарантируют доставку, а здесь нет.

Банально не был вызван, а в таблице данные корректны. В текущих версиях это очень редко, а ранее было не так и редко.

И когда она решит это вызвать? Когда цена уже пройдет две планки? Т.е. эту фразу я воспринимаю так: ориентируемся на колбек. Если он не пришел, каким-то образом, скорее всего с некой периодичностью читаем данные и сверяем. Т.е. данные подтверждаются с неким интервалом, возможно даже не таким и маленьким. Да, если считать, что колбек с вероятностью 99.99999 приходит, то можно предложить взять такой риск. Но я уже давно понял, что достаточно одного события с 10 сигма, чтобы потом очень сильно пожалеть. Тем более, что если скрипт не только для себя.

Ок. Предположим, что скрипт пишется корректно, и в колбеках только быстрое обновление информации, передача полученной информации в поток main.

Это предположение, а не факт. А также не отвечает на вопрос, что делать с пропусками, если блока чтения данных напрямую не предусмотрено.

Учитывать для чего? Если Вы не выполняете код в колбеке, а, как минимум, транзакции отправлять точно не стоит, то чтобы выполнить какое-то действие вы должны вернуться в mian. А значит эта задержка, какая бы она не была, есть постоянная для алгоритма.

Это просто субъективное соображение.



Ок. Пусть есть колбек для таблицы ордеров. Вы его обработали, что-то сделали с информацией. Можно, конечно, даже провести какие-то расчеты в колбеке, но тогда уже стоит учитывать, что данное решение будет плохо масштабироваться, на, скажем, 100 инструментов в одном скрипте. Рекомендация от разработчиков проста - взяли данные в колбеке и передали в main, и уже там с ней работает. И здесь возникает вопрос: если перед принятием решения необходимо иметь актуальную информацию и это мы делаем в main, то что мешает прямо перед принятием решения посмотреть на данные?

Если же колбек используется просто как светофор, то эту модель я как раз могу понять. У нас есть некий метод получения состояния портфеля или другой информации зависящей от сделок, установленных ордеров и т.д. И чтобы постоянно не опрашивать его, можно колбек использовать как сигнал для обновления. Сами данные все равно будет опрошены в main, но уже не постоянно, а по сигналу.

Еще один пример для колбека OnQuote. Я очень часто вижу как внутри этого колбека читают стакан и разбирают данные. И возникает вопрос - а точно понимают что делают?
Пришел колбек, что данные в стакане изменились. Хорошо. Для чего нам эта информация? Если необходимо фиксировать все изменения в потоке времени, а потом их анализировать, то да, другого выхода нет, необходимо читать и разбирать. А если данные стакана потребуются уже только в main, когда дойдем до некого метода где требуется информация о текущем состоянии, то прямо там и надо его прочитать один раз, если был сигнал от колбека. Т.е. сам колбек - это сигнал, что надо данные обновить. Пока дойдём до чтения в main, этот стакан изменится десятки раз. И все изменения кроме последнего - бесполезные.

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

О какой секунде речь - не понятно. Если речь про транзакцию, то после её подачи по номеру происходит поиск записи в таблице ордеров сразу, мгновенно. OnTransReply нужен только для того, чтобы прекратить поиск, если есть ошибка. Еще раз в момент принятия решения Вы просто смотрите на данные. Других данных у Вас нет.

И какое же преимущество у колбека (условно декларативного) перед императивным подходом? Что же такого это дает, кроме уменьшения кода, с чем не поспоришь. Также очень странно видеть "событийно-ориентированная архитектура" и "она предназначена именно для того, чтобы жить в мире, где события могут теряться, приходить не в том порядке или с задержкой". Как же жить если реакция на событие не пришла?

Вы исходите из того, что колбек в Квике - это гарантированное событие. Но это не так. Одно это уже заставляет просто даже не смотреть в их сторону. Потом скорость и асинхронность - я не очень понимаю этот довод, т.к. это тоже не гарантирует получения консистентных данных. Смотрим в сторону CAP теоремы. Колбек может прийти как до момента, когда Вам надо принять решение, а может после (а в подходе с ручным контролем можете сами опросить данные прямо в необходимый момент).  Если хотите больше гарантий, то, как минимум, необходимо строить систему, учитывающую команды всех скриптов, принимать решение с их учетом, например, учитывать транзакции по которым еще не получены ответы и данные по деньгам уже некорректны. Но даже если скрипт один, в момент принятия решения Вы не знаете о своем портфеле точной информации, банально потому, что данные которые видите - это прошлое. Настоящее оно на сервере биржи и приедет к вам через некую задержку. Поэтому для некоторых систем уменьшение задержек на 1 млс - стоит того, чтобы проложить отдельное оптоволокно сквозь горы.

Я использую такой же подход. Тем более что сканировать таблицы необходимо в любом случае при старте скрипта.

Правда такой подход уже сложнее реализовывать, если данные гоняются через socket в алгоритмы, написанные не на lua. Необходимо реализовывать свой колбек на стороне socket сервера, организованного также через сравнение числа записей. А также колбеки по изменению данных в записи таблицы, например, флага состояния или баланса.

Мои наблюдения тоже по брокеру Сбербанк. После принудительного обновления на последнюю версию, старт терминала стал очень долгим. Но не сам старт, а загрузка данных. Запуск и показ окна - это секунд 15. У меня не так много открыто окон. А вот потом начинается реальный тормоз. Примерно минут 5 уходит на загрузку данных, это видно по времени последнего пакета и времени сервера в строке состояния. Оно скачками изменяется и отстает на минуты 2 пока все не загрузится, и только тогда оно начинает изменяться по секунде. Т.к. скрипты стартуют с терминалом, то в момент долго старта явно видно, что обработка действий с таблицей происходит не то что медленно, а можно увидеть как обновляется информация построчно. Вспоминаю времена Word 2.0 на 386.

Рядом брокер от Альфа, они на версии 12.5 - запуск секунд 5, работа возможна практически сразу, по крайней мере, запускаясь вторым после Сбера, и пока он думает, здесь уже скрипты проверили данные и подали транзакции, ордера установлены. А Сбер так и думает пока.

Sleep здесь вообще не важен. Тем более, что если уберете его из main, то Квик банально встанет, что не говорит в его пользу и организацию работы с потоками.

Думаю, что для qlua такой проблемы вообще нет. Не те скорости. Это просто был пример для более тяжелых систем, не более.

Может и не надо. Ремарка была, т.к. прозвучало, что это потокобезопасно. Не более.

Мы не знаем как реализовали доп. поток в Квик. Реализовали ли макросы lua_lock вместо заглушек в lua исходниках. Хотя в этой давней теме https://forum.quik.ru/forum10/topic3270/ обсуждалось, что таки реализовали.

Да, но потокобезопасность - это гарантия, а не вероятность.

Потому что в момент получения размера, другой поток изменит last или first

-- Текущий размер очереди ---
function QueueSize(self)    return self.last - self.first + 1  end

Извлечь нет, а вот размер уже можно получить кривой. Плюс надо как-то гарантировать, что в двух потоках не будут разбирать очередь. Можно надеяться, что так не напишут, но это не гарантия, т.к. блокировок нет.
Хотя можно завернуть код в table.ssort

Это было не обсуждение, а просто комментарий, что иногда такой подход используют, когда порядок разбора очереди не столь важен.

Я только не очень понял, почему представленный пример называется двойная очередь, если это просто очередь как связанный список.
И как она стала потокобезопасной в Lua, где этого нет.

Когда я говорил о двойной очереди, я говорил именно о двух очередях.

Да ничего здесь нет глобального, просто кушать хочется. У Финама как было 45 копеек за контракт, так и осталось. У кого-то 1 руб. А другие решили, что процент от стоимости контракта - это способ убрать всех с срочки, т.к. для дорогих контрактов комиссия выходит просто гигантской. 0,015% от стоимости контракта - это "космос". Хотя, как ни странно, для опционов 50 копеек так и осталось.

Это у биржи.  Комиссию брокера никто не отменял. Прочитайте внимательно новые тарифы.

Если речь про глубину в 50 линий, то это давно у кого есть. Просто Сбер всегда выдавал 20 линий. После изменения комиссий у Сбера на срочном рынке - этот брокер только для Фонды. Платить в десятки раз больше за контракт - это безумие.

Так наступают времена, когда терминал останется только для проф. участников. Остальных попросят на выход. Альфа уже Квик выдает только квалам.
Был бы нормальный единый API давно бы уже ушли. А так пока у всех свои изделия, то проще через Квик. Но сдается мне, что Если ARQA не начнет реагировать, то это сделают другие.

DestroyTable нельзя вызывать в колбеке окна - это отражено в документации.
Вызывать OnStop руками, тем более в колбеке окна - тоже не надо.

Не ясна суть проблемы. Колбек окна - это транслятор команд в поток main, где все команды и надо обрабатывать. В окне перехватили событие - передали в main, там обработали.
Если вызван OnClose, то в нем производите проверки, устанавливаете состояние скрипта (или флаг) в остановлен и поток main уже проверяет это состояние, чтобы не вызывать ничего, т.к. в процессе остановки, а, наоборот, необходимо успеть выполнить процедуры корректного завершения - закрыть окна, закрыть, сохранить открытие файлы. Если в процессе ожидания OnStop не было ошибок выполнения, то скрипт прекрасно запустится вместе с терминалом. А если нет, значит и была ошибка, приведшая к падению main и остановке скрипта до завершения процесса остановки.

Этот колбек самый опасный. Читать таблицу обезличенных сделок лучше пакетами. У Вас цикл работы скрипта. допустим, 100 млс. За этот период набежит много сделок. Дойдете до процедуры чтения и все пачкой прочитаете от прошлого индекса. И так читаете, опрашивая не изменился ли размер таблицы. Колблек же будет занимать основной поток терминала просто говоря, что прошла сделка.

Свою.

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

Поэтому можно, и нужно, формировать разные очереди. И даже в рамках одной очереди, лучше использовать две, разбивая их на четные и нечетные. И писать, читать поочередно.
Записал в четную, потом в нечетную, потом четную, нечетную.
Читать нечетная, потом четная и т.д.
Это частично может помочь избежать блокировок. Или просто случайным образом выбирать какую очередь использовать первую.

Да и зачем смешивать очереди совершенно разных задач - обработка интерфейса и обработка транзакций. Но все эти решения будут требовать более сложной реализации планировщика задач.
Поэтому, зачастую, проще использовать одну очередь.

А зачем писать на диск, если mmap позволяет делать отражение в памяти.

Проверяйте, что не производятся расчеты в колбеках. Очень часто - это основная проблема. Более корректно - формировать очередь сообщений и разбирать в потоке main.

Но по субъективным ощущениям могу подтвердить, что последние версии терминала стали более легко уходить в ступор.

Не совсем так. Это ближе к чтению из таблицы текущих торгов. Если стакан открыт, т.е. поток данных уже есть, то можно читать без заказа. Поэтому и есть метод проверки существующего потока.

Колбек нужен для определения, что данные изменились. Если надо просто прочитать, то особого смысла в нем нет.

Если нужен именно весь стакан, то да, лучше заказать один раз и не закрывать. Хотя можете просто открыть руками в самом Квике.
Читать же можете только в необходимое время.

Если он не открыт, то надо вызвать Subscribe_Level_II_Quotes. Хотя можно проверить открыт есть ли поток данных через IsSubscribed_Level_II_Quotes, и если нет, тогда и заказать.
Делать это можно не в OnInit. Я бы даже сказал, что это точно не надо делать в OnInit.

Это уже сами решайте, что важно. У меня скрипты сами считают портфель по сделкам. Поэтому мне важнее таблицы сделок, ордеров. Да и бывает иногда, что брокера показывают нули в портфеле, в результате ошибок на сервере, хотя таблицы загружены.

Поэтому самое важное - это определить момент загрузки таблиц. А т.к. Квик не предоставляет методов для контроля этого, то приходится придумывать разные экзотические варианты.

Сам OnConnected не столь важен. Если вызван OnClenUp, то все данные таблиц пустые. А значит если логика скрипта проверяет данные из таблиц, то если не дождаться их загрузки, будут получены некорректные данные. А загрузка происходит совсем не мгновенно, иногда через минуты после прихода OnConnected.

Отступ можете ставить хоть 100 шагов. Но важнее другое - наличие алгоритма проверяющего состояние лимитного ордера по исполнению стопа через linkedorder. Если он не исполнился, то перевыставлять стоп от текущей цены или закрывать уже через алгоритм, подавая свой лимитный ордер от текущей цены. И тоже контролируя это, т.к. и от него цена может убежать. Да, такие ситуации не часты, и, скорее всего, 200 шагов хватит за глаза в спокойные дни, но достаточно одного случая, чтобы убыток стал в размер всех средств.

Ну так для Si 100 шагов = 100 пунктов. Это не особо важно. 100 шагов - это мало. Если думаете, что РТС не может шагать по 100 шагов, то обязательно поймаете такое событие. Впрочем, на моей памяти такое было не раз с 2008 года.

Проскальзывание не зависит зависит от трейдера. Если рынок ходит по 100 пунктов за тик, то это просто свойство рынка в данный момент. Какая там позиция и что думает трейдер - ему без разницы. Стоп-торги, возобновление и уже новая планка. И так далее. А лимитный ордер от сработавшего стопа так и висит.  

Это какой-то мир "розовых пони", 100 шагов для проскальзывания - это ничто. Без блока контроля убегания цены, вы получите "висящий" лимитный ордер, а цена пойдет дальше, оставляя позицию не закрытой, т.к. она проскочит цену пока этот стоп активируется, пока брокера подаст команду на лимитный ордер и он пройдет очередь желающих поскорее закрыть. Ситуация на рынке, когда цена скачет больше чем 100 шагов было так много. Поэтому даже установленный стоп у брокера, казалось бы должен закрыть, а он не закрывает. И потом пишут петиции - мол, как же так. Так что не контролировать, если используете стопы у брокера, не выйдет. Сервер брокера банально может зависнуть, а все риску на вас, о чем написано в договоре.

Если алгоритм не учитывает наличие планок (да и просто сумму стакана), то это опасно. У нас планка - почти нормальная ситуация.
100 - контрактов - это не такой и большой объем. Отношение ГО к объему контракта не имеет никакого отношения к числу контрактов. Для кого-то 10 контрактов - это весь депозит, а кому-то 100 - всего 10%.

Как много чудесных открытий Вас ждет. Если скрипт был остановлен, например по ошибке, терминал же работает. А во время простоя исполнились ордера, то колбеки пропущены, т.к. событие прошло. Колбек же - это реакция на событие. Иногда брокер может разорвать соединение, вызвать OnClenUp и тогда приедут ВСЕ колбеки с начала сессии. Но это исключение.

OnInit - это событие запуска скрипта, ни коим образом не связанное с таблицами. Если только при запуске Вы сами не проверите что изменилось в таблицах с прошлого запуска.

Учет комиссий не решается колбеками и данными из таблиц. Решается же он через обработку отчетов брокера. Комиссия биржи транслируется вместе с сделкой, поэтому её условно можно считать. Брокера же чаще всего транслирует "ерунду". И только в отчете за день будут точные цифры, т.к. они могу зависеть от оборота за день, типа инструмента и др, и в момент сделки точных банально нет. Так что гораздо проще в алгоритм вбить процент либо величину комиссии и учитывать её. А корректировать через разбор отчета брокера.

Ошибка т.к. обработка наивная:

pos = pos + sign*traded.qty

Естественно при таком подходе повторный вызов даст искажение данных. А если обработка более сложная, то не будет ошибки. Это уже вопрос реализации, зависящий от конкретной задачи.

Вы забыли данные из других источников. Индикаторы - это настолько малая часть и почти бесполезная часть, что её проще реализовать отдельно. Основное же использование - это скрипты, зачастую без интерфейса, а просто выполняющие расчеты, сохраняющие результаты в файлы. Так банально проще, т.к. анализ данных проще делать в других системах, в том же Python, а не в индикаторах Квика.
Даже если это торгующий скрипт, то не ясно зачем ему график. График нужен человеку, для самоуспокоения, что всё правильно.

Еще важно, что иногда набор данных включает очень далекую историю, которую Квик просто не может предоставить. Например, данные баров выгружались за 5 лет. На основе этих данных строится свой источник данных с ТФ, например, равный 12 минут, 3 часа, 5 часов и т.д. Квик просто не дает такие данные. И уже этот источник поступает на вход алгоритма. Этот источник будет состоять из двух частей - кэшированные, верифицированные данные (что очень важно) и текущие данные реального времени.

Также не редко у брокера бывают проблемы с данными. Например у меня один брокер три дня подряд пропускал данные за прошлый день. День прошел - данные были. Наступает следующий день - данных за прошлый день нет. Переподключения, сбросы - ничего не решает вопрос, т.к. это ошибка на сервере брокера. И так каждый день, возникает скользящая дыра в данных. Можно сказать - зачем такой брокер - ответ прост: я такое наблюдал у многих брокеров.

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

Нельзя ответить на этот вопрос. Например, если поля broker_comission и broker_comission_currency не важны, то этот второй вызов бесполезен, а если важны, то уже нет. Хотя, если говорить о комиссиях брокера, то они их может не транслировать вовсе и можно ждать вечно.

Т.е. все зависит от того, что необходимо. Явно поля количества и суммы важны, и, наверно, brokerref. Остальное уже решать Вам.

В системах с повторяющимися сигналами принято обновлять ранее поступившие данные. Пришли первоначальные данные - записали их с неким ключом. Пришли повторно обновили их и вызвали метод обновления зависимых данных. Т.е. если строить систему на простейшем принципе однократного учета, то будут проблемы. А если обновлять и пересчитывать, то уже нет. Хотя, конечно, обновление данных - это более сложная реализация. Иногда настолько, что проще не делать.

Радуйтесь, что в Lua нет понятия интерфейса, как концепции языка. Вот где начинается веселье. Но все же возникает ощущение, что Вы всегда уходите в процесс, вместо результата.
Углубится и написать фреймворк иногда полезно. Но все же, обычно, это процесс долгий. А для получения результата сейчас лучше пойти намного более простым путем.

Сразу возникает мысль, что не писали реального приложения через getCandlesByIndex.

Ожидание данных есть, т.к. скрипт с очень большой вероятностью запустится раньше, чем отрисуется график. А если происходит смена инструмента на графике, то возникает пограничная ситуация, когда тоже необходимо ждать, т.к. тоже отрисовка не мгновенна, да еще возникают неопределенности с изменением числа баров. Т.е. чтобы скрипт работал автоматически, необходимо реализовать методы перехватывающие все действия с графиком, совершаемые пользователем - смена инструмента, ТФ, нанесение индикатора, изменение настроек, закрытие графика. Все это приводит к тому, что в моменты работы скрипта он может обратиться к графику, а там данных нет или данные изменились. Всего этого просто нет в DataSource.

DataSource - это методы, да. Но в этом-то и преимущество, т.к. этим можно управлять. Реализовать новый метод возвращающий такую же таблицу, что и getCandlesByIndex - это несколько строк кода.

Синхронизация (временная) нескольких потоков данных - аналогична, т.к. отрисовка графиков тоже не одновременная. Точно также один обновится раньше другого.

Т.е. я ни вижу ничего такого, что не надо было бы делать в этом варианте. Если, кончено, наложить на пользователю жесткие ограничения - открыть график, подождать пока все покажется, только потом запустить скрипт. При смене инструмента - остановить скрипт, выполнить все действия, запустить скрипт. То можно максимально упростить алгоритм скрипта. Но назвать это удобным...

Впрочем, дело Ваше. напишите реализацию, поработаете, отловите все пограничные случаи и уже решите устраивает ли это. Может я чего-то не понимаю.

Здесь вопрос в излишней сложности. Если не зависеть от графиков, то реализация становится простой - надо всего лишь указать список ТФ, инструмент итак есть, если скрипт ведет портфель (он же должен знать что в нем). График открывайте для контекста, никто не мешает. Но и не открывая его - все будет работать.

В режиме чтения с графика необходимо реализовать все те же методы синхронизации, заказа и ожидания данных, что и в первом варианте. Но в дополнении к ним, ещё методы проверки корректности данных, получения информации о природе данных (чьи они, о чём они), обработки случайных закрытий, смены инструмента во время работы скрипта. Поэтому я не вижу здесь упрощения, а только усложнение как для разработчика скрипта, так и для пользователя. Пользователь тоже должен следовать определенному порядку в работе иначе будут ошибки.