"Если не знаете, то файловая система это тоже база данных." - это шедевр! А какой версии SQL там используется, СУБД тоже имеется? может, что то упустил за 25 лет в ИТ.
Ликбез: ------------------- Базы данных (БД) бывают разных типов, которые отличаются структурой и областью применения. Среди основных видов — реляционные, нереляционные, иерархические и сетевые, а также простейшие. ----------------------- Базы данных на основе файлов (flat-file databases) — это простой метод хранения данных в текстовом файле. В отличие от традиционных реляционных баз данных, в которых используются сложные структуры с таблицами, строками и столбцами, база данных с плоскими файлами организует данные линейным и последовательным образом. Особенности:
Каждая строка в файле представляет одну запись.
Отдельные поля внутри записи обычно разделяются разделителями, такими как запятые или табуляции.
Нет структур для индексирования или распознавания связей между записями.
Виды Базы данных с плоскими файлами подходят для небольших приложений и временного хранения данных. Некоторые случаи использования:
файлы конфигурации в программных приложениях;
обмен данными между различными системами;
файлы журналов, например, лог-файлы веб-сервера.
Форматы Для хранения данных в базах данных с плоскими файлами используются, например:
CSV (значения, разделённые запятыми) — каждое поле разделяется запятой.
TSV (значения, разделённые табуляцией) — в качестве разделителей используются табуляции, что полезно, когда запятые — часть самих данных.
Формат фиксированной ширины — каждое поле занимает заранее определённое количество символов, выравнивая данные по столбцам.
Инструменты Многие языки программирования и приложения имеют встроенную поддержку чтения и записи данных из баз данных с плоскими файлами. Например:
Программы для работы с электронными таблицами (Microsoft Excel, Google Sheets) — могут читать и работать с плоскими файлами.
Языки программирования (Python, Java) — могут анализировать и обрабатывать данные с помощью встроенных или сторонних библиотек.
Недостатки Базы данных с плоскими файлами имеют и ограничения. Некоторые из них:
Ограниченная масштабируемость — по мере роста объёма данных производительность базы данных может снижаться.
Отсутствие согласованности данных — если нужно обновить несколько записей, это становится утомительной задачей и увеличивает вероятность несоответствий.
Сложность извлечения данных — из-за отсутствия поддержки структурированного языка запросов (SQL) запросы часто требуют ручного сканирования и фильтрации через записи.
Ограниченный одновременный доступ — базы данных с плоскими файлами не предназначены для одновременного доступа нескольких пользователей или приложений.
------------------------------------------
SQL ( Structured Query Language — «язык структурированных запросов») — применяемый для создания, модификации и управления данными в реляционных базах данных. ----------------------- Нереляционные базы данных В нереляционных БД не используется табличная схема строк и столбцов. Применяется модель хранения, оптимизированная под конкретный тип данных. Некоторые типы нереляционных БД:
Документоориентированные. Данные хранятся в виде документов в форматах JSON, BSON или XML.
Колоночные. Информация хранится не в строках, а в столбцах.
Графовые. Данные представлены в виде графов, что упрощает их хранение и поиск.
- --------------------------- Для работы с нереляционными базами данных (NoSQL) используются специализированные языки запросов. Это связано с особенностями моделей данных в таких базах: данные могут храниться в виде документов, колонок, графов или на основе пар «ключ-значение». Ниже приведены примеры языков запросов для работы с базами данных MongoDB, Cassandra, BigTable и GraphDB.
MongoDB MongoDB Query Language (MQL) — язык запросов для документо-ориентированной базы данных MongoDB. Запросы формулируются как объекты JSON, что делает их интуитивно понятными. MQL поддерживает операции CRUD (создание, чтение, обновление и удаление), а также функции агрегирования для фильтрации, сортировки и группировки данных.
Cassandra Cassandra Query Language (CQL) — основной язык запросов для распределённой базы данных Apache Cassandra. Синтаксис похож на SQL, но оптимизирован для принципов NoSQL: горизонтальной масштабируемости, высокой доступности и партиционированного хранения данных. CQL не поддерживает традиционные SQL-соединения, а поощряет денормализацию — дублирование данных по таблицам для эффективного запроса.
BigTable Собственный язык запросов — BigTable не поддерживает язык запросов SQL. Запросы выполняются через API, который поддерживает ряд популярных языков программирования (Java, Python, C#, C++). Изначально нет схемы данных, но возможна поддержка пользовательской схемы.
GraphDB Cypher — язык запросов для графовых баз данных, например, Neo4j. Cypher — декларативный язык, позволяет создавать, обновлять и удалять вершины, рёбра, метки и свойства, а также управлять индексами и ограничениями. Другие языки запросов:
Gremlin — поддерживается базой данных Titan, позволяет выполнять базовые операции с элементами графа (создание, обновление и удаление вершин, рёбер, меток и свойств).
А Вы у брокера не спрашивали зачем он это делает? Может имеет смысл уйти от такого брокера?
У меня пять брокеров, а также есть логи работы скриптов, наверно, почти по всем более менее крупным брокерам. По опыту - у всех свои тараканы. Да и выйти в техподдержке на живого человека, который хоть как-то поймёт о чем речь - это тот ещё тот квест и уйма времени. Плюс, если такие события происходят, значит необходимо предусматривать такое поведение, мы же с деньгами работаем, а не картинки показываем на сайте.
В моей практики такого не было. --------------- Поясните подробнее, что означает появление новых заявок. Вы их не делали?
Nikolay написал: В последнее время один из брокеров стабильно стал разрывать соединение в середине торговой сессии и после восстановления соединения очищает таблицы, вызывает колбек OnCleanUp. Можно было бы сказать какого и зачем все чистить, но с этим уже бороться бессмысленно.
Более важно другое, после восстановления соединения в таблице ордеров наблюдаются совсем другие индексы записей. Был у записи индекс 15, а стал 20. Хотя визуально таблица (без фильтров и сортировок ) представлена именно как была ранее, и там запись до сих пор 15.
Ранее такого поведения не наблюдалось. Сейчас приходится вводить дополнительные методы для восстановления соответствия записей и запомненных данных.
А Вы у брокера не спрашивали зачем он это делает? Может имеет смысл уйти от такого брокера?
nikolz написал: Артем , Пишу алгоритм своего решения вашей задачи: Если понял ее не правильно, то уточните, что не так. --------------------- Алгоритм: 1) Создаем файл , в котором записываем в строку : Имя инструмента, A1,A2,....An где A1,A... - параметры наших индикаторов (уровней) Т е в файле столько строк, сколько всего инструментов наблюдаем Прим: Можно сделать для каждого инструмента свой файл. Имя файла ==имя инструмента. -------------------------- В опCalculate на кажом тике: 1) читаем имя инструмента 2)Читаем из файла строку параметров индикаторов данного инструмента 3) Выводим на график индикаторы
совершенно не понятное решение, в моем скрипте все уже реализовано через базу данных, зачем какие то текстовые файлы? я предельно четко сформулировал 2 вопроса. Вот они : 1) Как ПРОГРАММНО перевызвать Init или аналог его чтобы заполнить Settings ? (программный рестарт) 2) Почему нельзя прото добавить кнопку рестарт-реинит индикатора?(ручной рестарт, и избавить пользователей от опрации удали-добавь индикатор)
Если не знаете, то файловая система это тоже база данных. ----------------- Вы спросили как сделать так чтобы не руками без Init. Я Вам написал как это сделать. ----------------------- В моем решении нет надобности что-то делать руками и нет надобности вызывать init. В моем решении нет Ваших проблем. -------------------------- Про Ваш скрипт я лучше промолчу, чтобы вас не обижать.
Артем, Пишу алгоритм своего решения вашей задачи: Если понял ее не правильно, то уточните, что не так. --------------------- Алгоритм: 1) Создаем файл , в котором записываем в строку : Имя инструмента, A1,A2,....An где A1,A... - параметры наших индикаторов (уровней) Т е в файле столько строк, сколько всего инструментов наблюдаем Прим: Можно сделать для каждого инструмента свой файл. Имя файла ==имя инструмента. -------------------------- В опCalculate на кажом тике: 1) читаем имя инструмента 2)Читаем из файла строку параметров индикаторов данного инструмента 3) Выводим на график индикаторы
nikolz написал: Артем , Можете пояснить, почему надо именно в Init найти код инструмента.
Потому что только в Init есть возможность программно изменять параметры Settings, далее во время нахождения индикатора на графике мы можем менять параметры вручную и программно только считывать их. Все бы ничего если бы в индикаторе было до 10 параметров, но если их 50-100, это превращается в издевательство.
Правильно Вас понял, что Вы меняете параметры у встроенных в QUIK индикаторов. Поэтому так извращаетесь?. вставьте функции нужных индикаторов в скрипт и меняйте все что хотите у них
Встроенные индикаторы, меня не интересуютот слова совсем, у меня своих достаточно. Рассмотрим простой пример, есть индикатор в котором используется дневной ATR , как параметр. Покажите как программно изменить этот параметр в индикаторе при наступлении следующего дня. Можно зайти и руками поправить (супер), но становится грустно когда графиков штук 50, нужно найти этот ATR для каждого инструмента и забить ручками, при этом человеческий фактор никто не отменял. Здесь становится намного проще просто удалить-добавить индикатор, но тоже проделать данную операцию 20 -30 раз, такое себе.
Могу показать, если выложите скрипт И на примере подробно расскажите .
major написал: Вот два квика. В одном много вкладок в другом мало, в одном роботы в другом нет )))) Один память жрет другой проц ))))
в одном проц 3% а памяти 1,8 гигов в другом проц 12% а памяти 0,5 гига
У меня открыто 8 окон, на которых примерно 100 индикаторов. --------------- Легко нагрузить процессоры скриптами, так как функция Main без sleep или event грузить одно ядро до 100%..
При торговле у меня процессор грузится на 1-3%. Это тоже не напрягает. В это время либо пишу программы, либо смотрю фильм на втором мониторе, либо беседую с DeepSeek, либо гуляю по интернету. Если смотрю кино, то еще 12% нагрузка на CPU.
nikolz написал: Время начальной загрузки в большей степени связана с получением данных с сервера брокера.
Может быть у вас - да. Но остальные пользователи QUIK - не вы. У меня, например, QUIK гораздо дольше грузится до момента появления окна авторизации с сообщением "чтение файла данных".
у меня есть подтверждающее видео
1) с какой скоростью запускается мой торговый терминал 12 версии с 4 фьючерсами, очищенными логами 2) с какой скоростью запускается чистая 12 версия 3) с какой скоростью - чистая 8 версия (с такими же настройками, как у 12 версии)
с подтверждением конфигурации компьютера: i9-13980HX/64RAM/2TB SSD Можете пока погуглить характеристики этого процессора.
В этой части согласен. В этот момент строятся все графики и исполняются скрипты индикаторов аж по два раза. Но меня это как-то не напрягает. -------------------------- Я говорил от том моменте, когда связь с сервером установлена. Это тоже не влияет на торговлю. Но дело вкуса.
nikolz написал: Артем , Можете пояснить, почему надо именно в Init найти код инструмента.
Потому что только в Init есть возможность программно изменять параметры Settings, далее во время нахождения индикатора на графике мы можем менять параметры вручную и программно только считывать их. Все бы ничего если бы в индикаторе было до 10 параметров, но если их 50-100, это превращается в издевательство.
Правильно Вас понял, что Вы меняете параметры у встроенных в QUIK индикаторов. Поэтому так извращаетесь?. вставьте функции нужных индикаторов в скрипт и меняйте все что хотите у них.
VPM написал: nikolz, _ Ни о каком лучше или хуже речь не идет, речь о надежности, промышленной надежности. Мой пример реализован в модуле, то есть можно использовать в OnCalculate, так и в потоке main создавая псевдонимы функций.
Вот реализация для индикаторов
Код
Для меня, то, Ваш скрипт от 26.06.2025 15:35:14 выглядит излишне сложным. Я делал подобные конструкции лет 10 назад. ------------------ Ваше утверждение о "промышленной надежности" мне не понятно. ------------------- В общепринятом смысле, Промышленная надёжность — это свойство объекта сохранять работоспособность в течение заданного времени в определённых условиях эксплуатации. ---------------------- О каком объекте Вы говорите (Ваш скрипт ???), но это не промышленный объект. --------------------
Официально КВИК сделан для подачи заявок брокеру, которые брокер, согласно регламенту, исполняет, если может и когда сможет. ------------------- Других определений от разработчиков я не видел. ------------------------ Поэтому прикольно читать гневные требования клиентов брокеров к разработчикам QUIK. ------------------------- Разработчикам платит брокер за их продукт Брокеру платят его клиенты. Почему же свои претензии клиенты брокеров направляют не брокеру, а разработчику QUIK? -------------------------------- Кто знает ответ на этот вопрос?
VPM написал: На проблему озвученную в первом сообщении, там же есть ответ, проблема в версии, все что нужно для нормального вывода, выбросить данную фикцию, получить таблицу и вернуть необходимое количество линий?
Не есть и другой вариант: ждать год пока ответит разработчик, следующие 2 года будет исправлять, а в новой выпущенной версии, какой ни будь "молодой талант" все опять грохнет. На мой взгляд, подход тупиковый! А в целях надежности исполнения вычислений, такие функции нужно уменьшать в коде, лучше совсем убрать.
Извиняюсь что опять вмешиваюсь, просто хочу подсветить параллельную нерешенную задачу. Решение лежит в плоскости создания - универсальной, технологической обвязки, в которою можно было бы не опасаясь загружать любой алгоритм и она с ним справлялась, выдавая на гора результат. Примерный алгоритм такой обвязки я привел в своем примере выше (мягко говоря не идеальный вариант), а хотелось чтоб профессиональное сообщество обсудило, не в соревновательном режиме, а в рамках сотрудничества, чтоб получить надежный публичный вариант. Все одна только польза! ::
Можете доказать? Напишите два примера: для вашей реализации и альтернативной и покажи, что ваша реализация лучше, т е быстрее.
Роман написал: Вчера терминал был включён до конца торгов. Ночью соединение оборвалось, т.к. торги закончились. График остался. Сегодня подключаюсь (суббота) 6:20 МСК и график исчезает, подключение есть. Так происходит всегда - очищается график и если есть соединение с сервера QUIK, то данные приходят. Вопрос: зачем историю-то затирать? Как тогда проводить технический анализ, если при соединении стирается всё? Не логичнее было бы сделать, что если сервер с данными доступен, то стираем и закачиваем новые данные, а если не доступен, то и стирать не надо. На пустом экране тех анализ не проведёшь.
О какой истории Вы говорите? Если это свечи и индикаторы по ним то они сохраняются, а Вот индикаторы на основе параметров из ТТП обычно существуют лишь во время торгового дня если Вы их специально не сохраняете. ------------- Покажите картинку , что Вы отображаете и объясните , что исчезает.
Предположу, что У Вас большой архив данных. Попробуйте установить QUIK в новую папку. В итоге архив будет не более 3т свечей.
Я тоже это предполагаю. Но тест идет на акции Сбербанка, где число баров с утра на демо-сервере не более 100. Плюс хотелось бы понять как размер архивов по другим инструментам (график которых не открыт) влияет на производительность всего терминала.
Трудно что-то сказать, но я очевидно не понял проблему, так как на тесте, который запускал, не увидел ничего странного. Запустите свой тест у себя с выводом в лог файл как я добавил, что бы в логе увидеть то, что вам не нравится.
Впрочем, не исключаю, что возможно требуется техническая чистка терминала, т.к. этот комплект обновлятся с 7-ой версии. Но назвать это нормальным сложно.
Предположу, что У Вас большой архив данных. Попробуйте установить QUIK в новую папку. В итоге архив будет не более 3т свечей.
name= "test_lines"
lines = 100
Settings = {}
Settings.Name = "*"..name
Settings.price = 66960
Settings.delta = 1.0
path = "D:/QUIK_SCRIPT/"
local fn=path..name..".txt"
Log=io.open(fn,"w")
function Init()
Settings.line = {}
for i = 1, lines do
Settings.line = {}
Settings.line = {Color = RGB(185, 185, 185), Type = TYPET_BAR, Width = 2}
end
return lines
end
function OnChangeSettings()
Init()
end
function OnCalculate(index)
if index < Size() then return end
local x=os.clock()
for i = 1, lines do
SetRangeValue(i,index-100, index-1, Settings.price-i*Settings.delta);
end
Log:write("index="..index..","..x..","..os.clock().."\n"); Log:flush();
return
end
Вот результат работы Вашего теста: Я вывел в Log время построения линий вот что получил ------------------ index=127,1287.011,1287.012 index=127,1287.021,1287.022 ---------------- Т е все линии выводятся 1 ms. Версия qUIK 12.4.0.38. Все правильно? Какие проблемы?
function Init() Settings.line = {} for i = 1, lines do Settings.line = {} Settings.line = {Color = RGB(185, 185, 185), Type = TYPET_BAR, Width = 2} end return lines end
function OnChangeSettings() Init() end
function OnCalculate(index) if index < Size() then return end for i = 1, lines do SetRangeValue(i, index-100, index-1, Settings.price-i*Settings.delta) end return end
Поясняю. Вы стрите индикатор на 99 значений закрытых свечей плюс один тик текущей свечи. Какой в этом смысл. Полагаю, что у вас индикатор не изменяется назад на 99 свечей на каждом тике текущей свечи.
Nikolay написал: SetRangeValue(i, index-100, index-1, Settings.price-i*Settings.delta)
В примере каждый раз выводится 100 значений 100 линий. Это 10 000 вызовов функции SetRangeValue, в которой есть вычисления на луа. OnCalculate(index) вызывается на каждый тик. В результате у Вас цикл не успевает завершится до получения нового тика. -------------------------- Попробуйте измерить время вывода одного значения, чтобы понять где тормозит.
Игорь_С написал: Спасибо. Позвольте уточнить, все заявки выставлены программно, скриптом. Некоторые из них затем сняты программно, некоторые человеком. Можно ли средствами QLUA определить, какая из заявок снята пользователем, вручную., не обращаясь к брокеру.
Можно, например так. Если заявка снята (пришел колбек), а скрипт не посылал транзакцию на ее снятие, то это либо руками, либо брокер.
Пример не совсем тот. В примере Вы выводите значения с функциями Lua. Это н совсем то, когда вывод делается с помощью return ... значения индикаторов. ----------------------- Для чистоты эксперимента сделайте вывод значений через return. ------------------------- У меня 42 индикатора. Отображаются практически мгновенно. Версия 8.7.1.3
Предположу, что разместив QUIK на VPS , Вы решили проблему надежности соединения и безотказность работы, если эти проблемы у Вас были. -------------------------- Но при этом быстродействие торговли у Вас осталось на том же уровне, что и при торговле из дома.
yiv1 написал: Не знал о таком функционале. С чем можно сравнить чтобы понять "хорошие" или "плохие" показатели?
С тем же, но из дома. ---------------- У Вас пинг из дома меньше, чем задержка в QUIK VPS. ---------------------------- Задержка в QUIK - отражает реальную задержку обслуживания Вас сервером брокера.
ping q2.finam.ru
Обмен пакетами с q2.gslb - tt.finam.ru [ 78.41 . 199.16 ] с 32 байтами данных:
Ответ от 78.41 . 199.16 : число байт = 32 время = 7 мс TTL = 245
Ответ от 78.41 . 199.16 : число байт = 32 время = 7 мс TTL = 245
Ответ от 78.41 . 199.16 : число байт = 32 время = 7 мс TTL = 245
Ответ от 78.41 . 199.16 : число байт = 32 время = 7 мс TTL = 245
с VDS
Код
ping q2.finam.ru
Обмен пакетами с q2.gslb - tt.finam.ru [ 78.41 . 197.17 ] с 32 байтами данных:
Ответ от 78.41 . 197.17 : число байт = 32 время = 2 мс TTL = 246
Ответ от 78.41 . 197.17 : число байт = 32 время = 1 мс TTL = 246
Ответ от 78.41 . 197.17 : число байт = 32 время = 3 мс TTL = 246
Ответ от 78.41 . 197.17 : число байт = 32 время = 1 мс TTL = 246
А какую задержку показывает QUIK в информационном окне на VDS?
По картинке: 1 ядра хватит, 1 гб оперативки не хватит, 10 гб не хватит
QUIK может до 2гб оперативки использовать. Среднее потребление всех процессов в системе - 4,6гб Из 50 гб места занято на ~35гб, из них 20-25гб занято операционной системой (Windows Server 2016 с интерфейсом) Процессор загружен в среднем только на 5%, большую часть времени отдыхает.
Благодарю. Какая величина задержки обмена QUIK и время пинга с сервера до биржи и из дома до биржи.
Деус написал: В общем может кому-то поможет, ID транзакции это любое число, но у него есть ограничение в 32 бита а это значение ограничено числом -2147483648 до 2147483647 выше это ошибка и квик жалуется на это . Многие рандомайзеры или еще какие вещи которые вы используете в качестве Id могут генерить число выше этого значения. ЛУА: local trans_id = tostring(os.time() % 100000000) , Питон:now = datetime.now().isoformat() trans_id = str(int(datetime.now().timestamp() % 100000000)) . В тех поддержки ВТБ мне тоже не ответили сказали к разработчикам Квика идти :)
Разработчики перешли на Lua 5.3 именно потому, что ID стало 64 бит.
yiv1 написал: Так как есть полный контроль над ОС, можно собирать любые dll любыми способами на любом языке.
Благодарю за информацию. ------------ Можете подробнее рассказать о затратах памяти и диска. Вот на этом можно установить , то что у Вас. Если нет, то чего не хватает?
Nikolay написал: Судя по всему речь про реализацию колбеков как таковую. Сейчас - это просто триггер на любое изменение, без фильтров, что максимально быстро. А если делать фильтры, то уже всё усложняется - какие фильтры, почему такие, а не иные и т.д.
В этом плане для пользователя было бы хорошо иметь реализацию организации своего колбека. Например, того же OnParam, но своего. Текущий - это пожиратель ресурсов. Например, хочу иметь колбек на изменения таблицы текущих торгов с фильтрами по коду, классу инструментов и заданному списку параметров.
Что-то типа такого:
local on_param = SubscribeOnParam({'SBER', 'GAZP', 'SiU5'}, {'LAST', 'BID', 'OFFER'})
Т.е. мне не интересны другие коды и параметры. И таких подписок делать много, вплоть до одного инструмента, параметра.
Пусть эта реализация будет внутри терминала, и не влияющая на получение информации. Например, поток данных заходит в очередь, а сформированные колбеки её разбирают. Желательно отдельным потоком. И так для любых таблиц терминала.
Но это, как говорится, совсем другая задача. Кодировка до сих пор 1251, чего уж говорить об этом.
Сейчас колбеки реализованы очень просто. Перед обработкой пришедших данных из глобальной таблицы скрипта вызывается функция колбека, если она есть, и ей передаются параметры. т е все затраты - это вызов функции. Никакой обработки нет. Вы же предлагаете Все переделать ( добавить поток решать вопрос синхронизации нового потока с существующими и т д) Но брокерам этого не надо. А софт QUIK покупают брокеры.
Serge123 написал: Помнится, я уже спрашивал об уточнении док-ции по getQuoteLevel2... Надо, наконец уточнить: что возвращается в случае, если отсутствуют bid/offer? Это таблицы, поэтому логично возвращать nil. А в док-ции написано, что возвращается пустая строка. Если это так, то это бардак... Только что посмотрел описание этой функции в QLUA.chm (дата файла аж 2023 г.!) последней версии Quik. А между тем, ещё в 2016 г. запрос, якобы, начал рассматриваться: https://forum.quik.ru/forum10/topic1502/
Видимо, придётся самостоятельно проверять, что там возвращается: nil (NULL или 0 на Си) или ссылка на "". Но чтобы это проверить, нужно ждать конца вечерней сессии в 23:50. Он выглядит так (2 варианта):
В последних строках как раз надо выяснить, что именно возвращает getQuoteLevel2.
По идее, с этой целью можно также проверять строки bid_count, offer_count на символьный 0.
И ещё: моя программка на обработку
Код
static int forLua_OnAllTrade(lua_State * L)
тратит 6500 тактов ЦП, а на вызов
Код
static int forLua_OnQuote(lua_State * L)
{ .. .
lua_getglobal(L, "getQuoteLevel2" );
lua_insert(L, 1 ); // Используем код класса и тикер, которые уже сидят в стеке
lua_pcall(L, 2 , 1 , 0 );
тратит 202 000 тактов!! Нельзя ли как-то ускорить работу getQuoteLevel2?
Может быть, кто-то из программистов предложит ускорение? Я склоняюсь к тому, чтобы во время большой нагрузки на Quik не вызывать getQuoteLevel2, если с момента предыд. её вызова прошло мало времени.
Измерьте сколько затрачивает время каждый из операторов lua_getglobal(L, "getQuoteLevel2" ); lua_insert(L, 1 ); // Используем код класса и тикер, которые уже сидят в стеке lua_pcall(L, 2 , 1 , 0 ); а также пустая функция static int forLua_OnQuote(lua_State * L) Тогда можно сказать как ускорить и на сколько.
Возможно, причина в том, что запись в таблицу заявок производится после выхода из колбека. Поэтому, если обратится к таблице заявок в колбеке, то там будут старые данные. Т е при снятии заявки в таблице заявка будет еще активной, а в колбеке - пассивной.
Anton Belonogov написал: Если проблема с отображением линий на графике сохраняется, просим прислать на нашу почту quiksupport@arqatech.com скриншоты, иллюстрирующие проблему
Да я уже плюнул на отображение линий на графике. меня больше интересует почему у меня данные по сделке то подтягиваются в таблицу скрипта в начале утренней сессии, то не подтягиваются. Причем нет никакой закономерности. Скрипт может неделю работать без показа данных, а может пару дней показывать данные о сделке. Ну, вроде, не может программный код то работать, то не работать...Или может?
Попробуйте открывать квик в одно и тоже время. Например, за 5 минут до начала утренних торгов.
Юрий написал: Фактически фандинг — это механизм встроенного арбитража, разница между спотом и фьючерсом. Если ставка финансирования положительная: Цена контракта выше спотовой цены актива - Лонгисты платят шортистам. Если ставка финансирования отрицательная: Цена контракта ниже спотовой цены актива - Шортисты платят лонгистам.
Слежу за значениями фандинга четырёх инструментов уже месяц - значения всегда положительные ! Отрицательное значение вообще НЕ случаются? Т.е. вечные фьючерсы противопоказаны для покупки в лонг ? Такое ощущение, что народ даже не догадывается про это.... Или я ошибаюсь...
Если я не ошибаюсь, то вечных фьючерсов всего два. с октября 2024 года на Московской бирже представлены вечные фьючерсы на акции Сбербанка (SBERF) и «Газпрома» (GAZPF) ------------------ Вы за какими четырьмя следите?
Юрий написал: В таблице текущих торгов фьючерсов указывается величина Ставки переноса (фандинг) см. файл Непонятно с каким знаком эта величина в момент переноса в 18:50. Где можно смотреть знак фандинга положительный или отрицательный?