непонятно, у Вас на графике есть какие-то индикаторы и на них метки. Кидаете на этот график индикатор. В нем в функции init удаляете все метки и далее в onCalc рисуются новые. что не так?
Индикаторов нет. Есть всего один график.
Последовательность моих действий: 1. Открыл на графике SBER. 2. Поставил метки для SBER 3. Заменил SBER на ROSN на этом же графике. Метки SBER-а теперь не отображаются. 4. Поставил метки для ROSN 5. Переключился снова на SBER. Отобразились метки SBER-а, а метки ROSN теперь скрыты.
Как терминал понимает, какие метки надо отображать, а какие скрывать? Можно как-то программно это распознать, без записи в HINTы или массивы?
Полагаю, что ответ -никак. На разных графиках инструментов у Вас разные значения цены. Метки другого инструмента вне поля картинки. Попробуйте сжать масштаб по Y так чтобы он покрывал диапазон цен двух инструментов.
Нет, метка привязывается к графику (идентификатор графика привязан к графику, а не к инструменту). Варианты, типа как nikolz предложил, я не писал, так как там сложно: если руками метку удалили, то все идентификаторы при перезагрузке терминала сдвигаются). Перебором и проверкой всех существующих меток проще.
Это я понимаю, что метки в одной куче лежат. Но если я метку вручную поставил через меню, и не указал инструмент в HINT, то мне уже никак не понять, на каком инструменте я ее поставил? Сам торговый терминал распознает как-то.
непонятно, у Вас на графике есть какие-то индикаторы и на них метки. Кидаете на этот график индикатор. В нем в функции init удаляете все метки и далее в onCalc рисуются новые. что не так?
VPM написал: nikolz, Я не совсем корректно выразился
Цитата
VPM написал: nikolz , А код scite полностью покажите.
Имеется в виду строки, где вызываются разные версии Lua, в моем варианте это command.go.*.lua;*.macro=dofile $(FilePath) command.go.subsystem.*.lua;*.macro=3
файл lua.properties фрагмент из него запишите в конец файла:
VPM написал: nikolz, А код scite полностью покажите.
так я его не писал. Есть на официальном сайте. Работаю в основном на этой : SciTE Version 1.75 Apr 25 2009 11:30:59 by Neil Hodgson. December 1998-November 2007. http://www.scintilla.org Lua scripting language by TeCGraf, PUC-Rio http://www.lua.org -------------------- но есть эта: SciTE Version 3.7.5 Jan 16 2023 18:01:44 by Neil Hodgson. December 1998-May 2017. http://www.scintilla.org Lua scripting language by TeCGraf, PUC-Rio http://www.lua.org
[QUOTE]VPM написал: В SciTE, ну по крайней мере до версии указанной выше, в качестве внутреннего интерпретатора, используется Lua 5.1, и ее нельзя просто заменить на версию Lua 5.4. В статье выше был предложен вариант использования внешнего интерпретатора в моем случае это Lua 5.4, для этого был скачен
Код
[/CODE] [URL=/user/62/]nikolz[/URL], Тут видимо дело в версиях, в Lua 5.3 есть поддержка Lua 5.1, а Lua 5.4 уже нет такой поддержки, да и изменения есть серьезные, которые не поддерживаются в ранних версиях.
[URL=/user/3132/]Nikolay[/URL], Так ведь просто удобно, нажал кнопочку и привет. Потом просто привычка, быстрая проверка кода, не отходя от "кассы". [QUOTE]
[/QUOTE]
[/QUOTE]
вот запускаю скрипт в lua5.4 Он работает и в lua 5.3 и и lua5.1[CODE]>D:/lua54/lua54.exe -e "io.stdout:setvbuf 'no'" "test2020.lua"
>Exit code: 0
VPM написал: Скорее всего на прямую и нельзя, один и тот же код, выводит:
использую лишь компилировать и выполнить(Lua 5.3. ) это исполнение теста(получение данных с биржи):
Код
>D:/lua53/lua53.exe -e "io.stdout:setvbuf 'no'" "Moex.lua"
engines
id;name;title
1;stock;Фондовый рынок и рынок депозитов
2;state;Рынок ГЦБ (размещение)
3;currency;Валютный рынок
4;futures;Срочный рынок
5;commodity;Товарный рынок
6;interventions;Товарные интервенции
7;offboard;ОТС-система
9;agro;Агро
1012;otc;ОТС с ЦК
1282;quotes;Квоты
markets
id;trade_engine_id;trade_engine_name;trade_engine_title;market_name;market_title;market_id;marketplace;is_otc;has_history_files;has_history_trades_files;has_trades;has_history;has_candles;has_orderbook;has_tradingsession;has_extra_yields;has_delay
5;1;stock;Фондовый рынок и рынок депозитов;index;Индексы фондового рынка;5;INDICES;0;1;0;1;1;1;0;1;0;0
1;1;stock;Фондовый рынок и рынок депозитов;shares;Рынок акций;1;MXSE;0;1;1;1;1;1;1;1;0;1
2;1;stock;Фондовый рынок и рынок депозитов;bonds;Рынок облигаций;2;MXSE;0;1;1;1;1;1;1;1;1;1
Добрый день, Всем С момента появления VMLua в КВИКЕ неоднократно рассказывал о том, что применение event вместо sleep не только экономит ресурсы процессора, но и позволяет не пропускать события в колбеках и максимально бысто на них реагировать. говорил об этом например здесь: https://forum.quik.ru/forum17/topic8426/ --------------------- К сожалению, кроме бессмысленного хамства некоторых посетителей форума, ничего конкретного никто не написал. --------------- Но вот наконец-то появился вменяемый чел paluke . и после моей попытки в очередной раз объяснить преимущество event https://forum.quik.ru/messages/forum10/message75435/topic8600/#message75435
он все же решил проверить это и убедился, что это так действительно:
Код
Просто проверка концепции:
Кодw32 = require("w32")
run = true
evt = false
function OnInit()
evt = w32.CreateEvent(nil, 0, 0, nil)
end
function OnStop()
run = false
w32.SetEvent(evt)
end
function main()
while run do
w32.WaitForSingleObject(evt, 1000000)
end
w32.CloseHandle(evt)
end
В колбеках вызываете SetEvent - main сразу просыпается.
nikolz написал: как вы предполагаете изменить значение локальной переменной. Она не передается как таблицы по указателю, поэтому Вы не получите к ней доступ в функции, а получите ее копию.
Странное рассуждение... Адрес структуры для локальной строки передаётся в виде указателя в параметре при вызове из Lua скрипта моей dll.
А вдруг кто-то знает, но не хочет сказать... Вот TGB, по-моему, глубоко копает.
Вы на ходу придумываете? Вы хотя бы смотрели что написали. Где в вашем примере структура?
Код
local str = 'abc'
--------------------------- "Один дурак может задать столько вопросов,что сто мудрецов не смогут ответить"
Роман написал: Подскажите, почему при использовании в скриптах функции 'unpack' может возникать такая ошибка "LuaIndicators\SO.lua:61: attempt to call a nil value (global 'unpack')"? Хотя индикатор от разработчиков и без скрипта в терминале он таких ошибок не вызывает.
LuaIndicators\SO.lua:61: attempt to call a nil value (global 'unpack')"? -- попытка вызвать nil значение. в строке 61 ---------------- Это старая версия индикаторов для Lua 5.1 в которой unpack был глобальной функцией -------------- сейчас в квике используется версия 5.3 .и 5 .4 в них функция unpack перенесена в библиотеку table. ----------------- Надо в скрипте вместо unpack записать table.unpack
Вы учтите, что за все что ММ выставит против рынка биржа ему заплатит. Если ММ будет каждую ms выставлять по 1 заявке против рынка и биржа будет платить ему 1 руб за заявку, то 10 часов торгов он получит 36 млн. руб. в день. Разве этого мало? --------------------------- HFT роботы тем и страшны для обычных трейдеров, что они как пираньи нападают быстро кусают понемногу, а в итоге быстро скушают и слона.
При этом str не используется для индексирования в таблицах, т.е. нет такого: table.str ...
Похвально, что Вы интересуетесь такими вопросами, на которые скорее всего Вам на этом форуме не ответят. Но чтобы ответить Вам на него мало информации. ---------------- Попробуйте уточнить следующее: как вы предполагаете изменить значение локальной переменной. Она не передается как таблицы по указателю, поэтому Вы не получите к ней доступ в функции, а получите ее копию. т е чтобы изменить ее из DLL надо сделать хорошие грабли и достать большой бубен.
Смысл в том, что ММ ставит встречную сделку и и если Вы выставляете по рынку и бъете в заявку MM, то ему(ММ) биржа платит денюшку. ----------------------- Поэтому он и ММ.
Serge123 написал: Видимо, имелось в виду, что длл получает инфо, что коллбэк что-то записал в очередь, и длл запускает main, которая всё остальное время спит. Или что-то подобное.
Если не ошибаюсь, Вы осваиваете написание dll для луа. Вроде бы уже выкладывал исходник для event и wait ----------------- Можете взять библиотеку w32 для Lua:
nikolz написал: Кроме того, у меня нет sleep. Поэтому задержка на обработку любого колбека не более 0.1 ms. Это на порядки меньше чем задержка со sleep.
Здесь я не понял, о каком sleep идёт речь. У меня в скрипте sleep(10) используется один раз в main в цикле обработки очереди от коллбэков. В Lua по-моему нельзя прервать паузу, если в мой массив (очередь) коллбэк что-то записал.
Да именно sleep в main. Когда очередь main остановится на указанное время. Все это время колбеки будут забивать очередь и даже для sleep(10) . Но при sleep(10) будет пустая трата времени ядра. Посмотрите сколько у вас будет загрузка процессора, если sleep(10) или sleep(1000). ------------------------- Вместо sleep ставим wait в и создаем event. в итоге main просыпается сразу по срабатыванию колбека и спит произвольное время, если сигналов нет. Пустой траты времени нет совсем. И main реагирует на колбек примерно в 100 раз быстрее. ------------- Кроме того, с помощью wait можно реализовать дополнительно запуск main по таймеру. --------------- Например, делал так: -------------------- main запускается колбеками, но не реже 1 раз в секунду(10 секунд).
nikolz написал: так как вызов функции getQuoteLevel2 существенно меньше рисования стаканов.
А у Вас обработка сравнима по времени с getQuoteLevel2 и другими необходимыми Вам вызовами qlua? Я тестирую на том, чем сам потом пользоваться буду, для меня пока нет разницы. В очереди для стаканов не вижу смысла, кстати, я просто хэш-таблицу заюзаю с ключами по sec и содержимым sent,updates,received,стакан.
Обработка сравнима. Создаю потоки из пула системных потоков и в них запускаю Luajit (из всего, что пробовал это быстрее всех работает). В указанном ранее тесте в отдельные моменты создавалось максимум 11 потоков. ------------------ Я не рисую стаканы. Скальпингом не занимаюсь. Использовал стакан при реализации алгоритма закрытия позиции по стопу. Но в основном использую либо лучшие предложения либо по рынку, так как торгую лишь ликвидными акциями.
Я провёл тест, который не выявил разницы. Может быть, getQuoteLevel2 не нужна синхронизация? Запустил два почти одинаковых скрипта, рисующих стакан каждый в своём потоке (настроено так, чтобы гуи рисовался в main скрипта, а не в главном потоке квика). Ниже часть кода одного из скриптов с комментами про замены, чтобы получить второй скрипт. Единственная стабильная разница, что вызов в main даёт на 1 секунду больше CPU time, хотя этот скрипт был запущен на 4 секунды позже (запускал в дневной клиринг, как видно на скрине, чтобы не было обновлений стакана на срочке)
Код
Мы с Вам о принципиально разных решениях говорим. -------------------------------------- В вашем тесте - один инструмент, стакан которого вы рисуете. В этом случае Вы не заметите разницы, так как вызов функции getQuoteLevel2 существенно меньше рисования стаканов. ============== Моя постановка задачи для теста такая. ---------------------- Торгуется портфель инструментов. Поток main работает по событиям. Все события формируют очередь(может быть несколько очередей) ---------------- 1) В этом случае, если getQuoteLevel2 вызывать в колбеке, то в очередь попадет весь стакан и clas и sec. Т е время работы колбека всегда будет включать запрос стакана. ========= 2) Если в колбеке не запрашивать стакан, то в очередь запишется clas и sec. Т е время работы колбека будет меньше всегда, чем в первом случае. -------------------- В main будет вызываться функция getQuoteLevel2 . Она находится в глобальном стеке и обращение к ней уже синхронизировано в библиотеке QLUA. Но так как к ней никто вне main не обращается, то ее вызов не будет ничего тормозить и ничего блокировать не надо. ------------------ Если рынок очень активен, то в первом варианте Вы получите целую толпу стаканов, которые уже устарели. --------------------- Во втором варианте в очереди будет всего один колбек и в main будет прочитан самый последний стакан. -------------------- У меня робот работает именно так.
Serge123, Если хотите определить причину, то запишите в лог значения времени : время выставления заявки скриптом, время колбек транзакции время колбека заявки время колбека сделки ----------------- По этим данным Вы увидите что тормозит. ----------------- Относительно тормоза при проигрывании музыки Специально для вас выкладывал исходник с асинхронным проигрыванием. Чтобы не ждать, надо в нем установить второй параметр 0.
Игорь М написал: Если вы на открытии сделки совершаете, то помимо непосредственно ваших сделок ещё и большой поток информации в эти моменты приходит, поэтому Квик это тяжело переваривает.
Да, я видел, что причина торможения во время моих сделок в том, что иногда почему-то идёт большое число мелких сделок, напр., десятки сделок по 1 акции. Я так и не могу понять, зачем кто-то выставляет заявки по одной акции, как будто кто-то отлаживает свою программу или что-то тестирует. Если нет потока мелких сделок, то торможения нет.
По одной заявке выставляют HFT роботы, скальперы и ММ.
Игорь М написал: Предполагаю, что Сергей описывал ситуацию зависания при приходе его личных сделок ("когда идёт много моих сделок, я ясно вижу торможение") , хотя конкретики мало дал. Отключать алгоритм Нейгла ему смысла нет. Его никто не отключает и у всех всё работает, значит, не в нём дело.
Точно, я даже предположил, что особенно на задержку влияют звуковые сигналы. Какая нужна конкретика? Где-то до октября 2023 я и в утреннюю и в вечернюю сессии удачно выставлял заявки с пом. скрипта, иногда даже видел по содержимому стаканов в файле, что я в очереди первый. Первым быть не всегда хорошо, потому что во время премаркета бывает в сумме крупная встречная заявка, за это снимают деньги. Но потом перестало получаться попадать в начало очереди на вечерней сессии (а утром по-прежнему всё ОК). Такое впечатление, что мосбиржа вечером варьирует время начала приёма заявок в пределах 2 секунд. То ли вечером возникли какие-то задержки (в том числе с получением ответов от сервера на заявки). Поэтому я и решил попробовать вечером отключить алгоритм Нейгла, но от этого получился полный затык в работе Квика.
Попробуйте вывести в лог файл время прихода колбеков OnTransReply и OnOrder и сравните с временем регистрации сделки из таблицы сделок. Если выложите эти времена, то можно будет что-то конкретное сказать.
nikolz написал: В моем тесте использовался колбек опParam , а это и есть сообщения, которые отображаются в ТТП. Там не только сделки, но и любые изменения по инструменту. Тест выставлял заявки по инструменту, по которому совершена сделка. Снимал заявку, когда она зарегистрирована сервером, т е выставлена в стакан. Тормоз 2-3 секунды наблюдается в КВИКЕ, если много окон и других приложений открыто. Я такое наблюдал давно на одноядерном компе по XP. ------------------ Можно увидеть это вечером, когда мало сделок или на неликвиде.. --------------- Но что конкретно происходит без логов сказать точно невозможно.
Видимо, тут и есть недопонимание. Я писал про сделки совершенные мной лично и таблицу сделок в режиме их прихода. Когда их разом приходит много, бывают (не всегда) зависания по 2-3 секунды (окна и прочее у меня всегда одни и те же). Поэтому ваш тест не показателен, он про другое. Предполагаю, что Сергей описывал ситуацию зависания при приходе его личных сделок ("когда идёт много моих сделок, я ясно вижу торможение") , хотя конкретики мало дал. Отключать алгоритм Нейгла ему смысла нет. Его никто не отключает и у всех всё работает, значит, не в нём дело. Вы первый человек на моей памяти, который его отключал.
Предположу следующее. Зависит от того каким образом обрабатывать таблицы сделок и заявок. В моем случае в таблице заявок в конце теста было 200 000 строк, но я обрабатываю колбеки до появления соответствующих изменений в таблицах. Поэтому я не лезу в эти таблицы. Если туда ходить, то задержки существенно увеличиваются. ------------------- Кроме того, у меня нет sleep. Поэтому задержка на обработку любого колбека не более 0.1 ms. Это на порядки меньше чем задержка со sleep.
Вызвать regedit, перейти в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\P arameters\Interfaces\ и далее зайти в подветку, где есть параметр DhcpIPAddress, который равен моему IP. Добавить/изменить 2 параметра (вначале их там нет): DWORD 32 бита TcpAckFrequency и TCPNoDelay со значением 1. Для его восстановления надо установить эти 2 параметра в 0. Для вступления в силу изменённых параметров надо перезагрузить ПК.
вроде все так. Этот алгоритм с давних времен отключают для игр по интернету. ----------------------- проверил ничего не виснет.
В 2023 году Мосбиржа запустила Algopack и выложила на Гитхаб библиотеку на python – moexAlgo,
которая должна упростить работу с AlgoPack API.
AlgoPack — это данные, сигналы и аналитика для алгоритмической торговли через API
Загружать большой набор исторических данных
Тестировать свои торговые гипотезы
Построить алгоритмическую торговлю
В рамках интерфейса доступны следующие типы информации: статические данные о рынках (режимы торгов и их группы, финансовые инструменты и их описание), данные для построения графиков ("свечей"), сделки (анонимно), котировки, исторические данные, различные метаданные.
Аналогично продукту MOEX Trade INFO, который также работает через ИСС,
данные могут предоставляться или по подписке в режиме реального времени или в свободном доступе (без авторизации, но с задержкой).
Взаимодействие с сервером осуществляется по протоколу http.
На питоне работает. свечи: period_map = {'1m': 60, '10m': 600, '1h': 3600, '1D': 86400, '1W': 604800, '1M': 2678400, '1Q': 8035200} ---------------------- Использую для создания истории для ИИ на основе FinRL: Библиотека глубокого обучения с подкреплением для автоматизированной торговли акциями https://github.com/AI4Finance-Foundation/FinRL на питоне работает. версия питона не выше 3.10 выше тоже можно, но сложнее. работаю на 3.12.
nikolz написал: Возможно Вы знаете, но причина тормозов при отправке заявки может быть из-за алгоритма Нэгла.
Я попробовал его отключить, но Квик начал очень сильно тормозить, занятость ЦП 82%, только и делал, что крутил бублик вместо курсора мыши, я не смог ничего сделать. Поэтому отключение этого алгоритма не для этого 2-ядерного ПК. Попробую на другом ПК.
Если правильно отключаете, то этого быть не может даже теоретически. алгоритм не связан с числом ядер. Он просто не отсылает Ваши пакеты в интернет пока они не станут большими или не пройдет достаточно много времени. Если Вы ничего не посылаете, то нет никакой разницы включен он или нет.
Nikolay написал: Это не очень нормальное поведение. У меня бывает до 1000 транзакций. Каких-то особых "зависаний" не наблюдается.
Цитата
nikolz написал: В результате 4 часового теста было выставлено и снято более 200 тысяч заявок (это 400 тысяч транзакций) по 200 инструментам. Никаких тормозов я не заметил.
Как я понял, он про сделки писал, а не про транзакции. На транзакциях у меня тоже не наблюдается задержек, а когда много сделок приходит разом, бывает что бублик 2-3 секунды крутится, особенно, если в этот момент пытаешься в Квике что-то делать. При этом в лог всё в нормальное время пишется без особых задержек, так что я не думаю, что здесь проблема из-за интернета. Для процессора на 4ГГц будет задержка в 1-1,5 секунды в подобной ситуации и на неё внимание просто не обращают. Прямая зависимость времени зависания от количества поступивших на обработку записей в таблицу сделок и частоты процессора. Сергей не написал какое количество записей в таблицу сделок пришло, какой у него проц по частоте и сколько зависание в секундах длилось, а так по его описанию у меня тоже бывают такие моменты, но 2-3 секунды это не проблема, конечно.
В моем тесте использовался колбек опParam , а это и есть сообщения, которые отображаются в ТТП. Там не только сделки, но и любые изменения по инструменту. Тест выставлял заявки по инструменту, по которому совершена сделка. Снимал заявку, когда она зарегистрирована сервером, т е выставлена в стакан. Тормоз 2-3 секунды наблюдается в КВИКЕ, если много окон и других приложений открыто. Я такое наблюдал давно на одноядерном компе по XP. ------------------ Можно увидеть это вечером, когда мало сделок или на неликвиде.. --------------- Но что конкретно происходит без логов сказать точно невозможно.
VPM написал: Nikolay, Легкий поток в Lua - это сопрограмма, которая может быть приостановлена и возобновлена независимо от основного потока приложения. Это позволяет выполнять код асинхронно, не блокируя основной поток. Легкие потоки являются более легкими и эффективными, чем потоки операционной системы, что делает их подходящими для приложений с большим количеством одновременных задач. Именно этот подход я и хочу обсудить, применительно к нашей прикладной задачи. Отслеживать события способом сопрограмм с обратным вызовом, ну к примере как Вы предлагали сделать общею таблицу событий и ее обрабатывать, удобней наверно даже в виде класса, что можно было масштабироваться и забыть про эту проблематику.
По-моему мнению, Вы ошибаетесь. Если железо одноядерное, то последовательное выполнение - это есть блокирование . При сопрограммах у вас основной поток луа останавливается. иначе это будет параллельное исполнение. Я говорил выше, что сопрограммы это всего диль отдельный стек для луа машины. т е не надо сохранять содержимое основного стека , так как отельный стек не занимается основным потоком. При работе с сопрограммами делается просто переход на другой стек вместо его сохранения и восстановления. Это позволяет прерывать исполнение функций в лбом месте и продолжат их исполнения с этого места. Это все. Но все это последовательно с остановкой всех , кроме одного.
VPM написал: nikolz, Ну о какой Вы последовательности исполнения говорите, событие или пришло в основную последовательность, забрав на себя исполнение, и сломав последовательность, или не пришло и все исполняется последовательно. На минутку подставим что у нас не одно событие, а отслеживаем несколько? И каждое выскакивает когда вздумается. Похоже нужно дать определения. Но ведь у нас не абстрактные рассуждения мы говорим о луа (а это значить по умолчанию один поток). последовательность исполнения в котором постоянно ломают сопрограммы.
Не соглашусь с Вами. Обычно механизм прерываний по одной из двух схем. 1) Для событий делается очередь. События обрабатываются из очереди. пришло новое , встало в очередь. Если у событий есть приоритет, то оно может прервать выполняемое событие, если оно ниже по приоритету. 2) Пришло событие. Оно блокирует прием новых событий до исполнения этого. ---------------- Обе схемы обеспечивают последовательное выполнение событий. ---------------- Я говорю не абстрактно. Именно так реализуется обработка событий на уровне железа и OC. --------------------- Кораунды это яля потоки на уровне виртуальной машины. Бесспорно, так как железное ядро одно, то все работает последовательно. ----------------------- Если софт написан правильно, то ничего никто не ломает.
Мое понимание сопрограмм такое: ------------------------- Сопрограмма это VMLua, для которой выделен локальный стек в области памяти основной VMLua. ---------------------------- Поэтому у сопрограммы и основной программы общие глобальные переменные и функции. ------------------------- Запуск скрипта как сопрограммы позволяет останавливать выполнение скрипта сопрограммы и не портить локальные параметры функции,которая вызвана как сопрограмма, так как у каждой сопрогаммы свой стек VMLua. ---------------------- Если функцию вызвать без создания сопрограммы, то другая функция может быть запущена лишь по завершению этой, так как они исполняются в одном стеке ---------------------------- Использование сопрограмм не приводит к параллельному вычислению, а лишь позволяет последовательно исполнять функции по частям. -------------------------- В QUIK сопрограмма запущена в отдельном потоке и называется main.
И ещё я вижу торможение, когда окно "Доступные скрипты" располагаю поверх стаканов. В этом случае хорошо видно, что циферки занятости памяти напротив скрипта перерисовываются не мгновенно. Хотя, GPU в диспетчере тоже простаивает, как и CPU. Поэтому я не знаю, как объяснить это торможение. Если перенести это окно на фоновую область окна Квика, то циферки рисуются мгновенно.
Перед началом работы я в диспетчере задач на всякий случай ставлю процессу info.exe высокий приоритет. Но каких-то изменений в связи с этим я не заметил.
Сказать, что конкретно у Вас тормозит не делая лог файлы не реально. ------------------ Могу лишь рассказать результаты моих тестов, которые указывают на то, что КВИК может работать очень быстро. Я выкладывал результаты КРАШ теста, который делал на демо сервере. В тесте я принимал инструменты по колбеку onParam и выставлял на принятый инструмент заявку на покупку в очередь, После подтверждения регистрации заявки на сервере, я отменял ее. В результате 4 часового теста было выставлено и снято более 200 тысяч заявок (это 400 тысяч транзакций) по 200 инструментам. Никаких тормозов я не заметил. Терминал тратил на отправку очередной транзакции не более 0.1 ms. ----------------- После этого теста получил предупреждение от разработчиков, чтобы больше так не грузил их сервер. ------------------------ Поэтому полагаю у Вас может быть либо проблема с Вашим скриптом, либо с Вашим брокером. Сделайте вывод в лог файл в колбеке и в main и сделайте анализ задержек.
paluke написал: Ну например, может оно как-то использует оконные сообщения.
Сомнительно: не видно логики для неработоспособности этой функции в консольных программах. И в документации на сайте МС нет такого предупреждения... Аналогично для более современной функции PlaySound. Как тогда МС вообще планирует использование звука в консольных программах??
Вроде все работает. Попробуйте сделать такую функцию в dll и добавьте sF в таблицу luaL_Reg В данном примере это luaL_Reg nks[]
nikolz написал: вот пример сделок по одной цене и время все в пределах 200000 мкс и таких много:
И что? Долбят по мелочи заявку маркетмейкера на миллиард. А потом маркетмейкер решил подвинуться на один пункт и сгреб всех разом...
Время сделки должно совпадать со временем регистрации заявки, вызвавшей эту сделку. Иначе будут вопросы: "Почему по моей заявке сделка прошла по более высокой цене, хотя последняя сделка по низкой цене была на пять микросекунд позже, чем зарегистрирована моя заявка?"
Не соглашусь с Вами. По-моему, маркет мейкер не выставляет очень большие пакеты. ----------------- Я предположил что это сделка РЕПО. ММ эти сделки не делает. РЕПО - это передача акций в долг. Эти сделки делают проф участники между собой.
Нет, ядра у Вас не сильно заняты. Вы можете это увидеть в диспетчере задач. -------------------- У Вас в main используется sleep(1000) т е Вы останавливаете поток Main на 1 секунду. В винде квант, который выделяется задаче составляет 15 ms. У Вас VMLua в потоке работает 1 квант из 60, т е примерно 2% доступного времени.