В 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: Библиотека глубокого обучения с подкреплением для автоматизированной торговли акциями
на питоне работает. версия питона не выше 3.10 выше тоже можно, но сложнее. работаю на 3.12.
Почему в этой программке утекает память??
Пользователь
Сообщений: Регистрация: 30.01.2015
22.04.2024 07:20:49
, Я отключал этот алгоритм даже на одноядерной машине.
написал: Возможно Вы знаете, но причина тормозов при отправке заявки может быть из-за алгоритма Нэгла.
Я попробовал его отключить, но Квик начал очень сильно тормозить, занятость ЦП 82%, только и делал, что крутил бублик вместо курсора мыши, я не смог ничего сделать. Поэтому отключение этого алгоритма не для этого 2-ядерного ПК. Попробую на другом ПК.
Если правильно отключаете, то этого быть не может даже теоретически. алгоритм не связан с числом ядер. Он просто не отсылает Ваши пакеты в интернет пока они не станут большими или не пройдет достаточно много времени. Если Вы ничего не посылаете, то нет никакой разницы включен он или нет.
написал: Это не очень нормальное поведение. У меня бывает до 1000 транзакций. Каких-то особых "зависаний" не наблюдается.
Цитата
написал: В результате 4 часового теста было выставлено и снято более 200 тысяч заявок (это 400 тысяч транзакций) по 200 инструментам. Никаких тормозов я не заметил.
Как я понял, он про сделки писал, а не про транзакции. На транзакциях у меня тоже не наблюдается задержек, а когда много сделок приходит разом, бывает что бублик 2-3 секунды крутится, особенно, если в этот момент пытаешься в Квике что-то делать. При этом в лог всё в нормальное время пишется без особых задержек, так что я не думаю, что здесь проблема из-за интернета. Для процессора на 4ГГц будет задержка в 1-1,5 секунды в подобной ситуации и на неё внимание просто не обращают. Прямая зависимость времени зависания от количества поступивших на обработку записей в таблицу сделок и частоты процессора. Сергей не написал какое количество записей в таблицу сделок пришло, какой у него проц по частоте и сколько зависание в секундах длилось, а так по его описанию у меня тоже бывают такие моменты, но 2-3 секунды это не проблема, конечно.
В моем тесте использовался колбек опParam , а это и есть сообщения, которые отображаются в ТТП. Там не только сделки, но и любые изменения по инструменту. Тест выставлял заявки по инструменту, по которому совершена сделка. Снимал заявку, когда она зарегистрирована сервером, т е выставлена в стакан. Тормоз 2-3 секунды наблюдается в КВИКЕ, если много окон и других приложений открыто. Я такое наблюдал давно на одноядерном компе по XP. ------------------ Можно увидеть это вечером, когда мало сделок или на неликвиде.. --------------- Но что конкретно происходит без логов сказать точно невозможно.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 30.01.2015
22.04.2024 07:08:56
Цитата
VPM написал: , Легкий поток в Lua - это сопрограмма, которая может быть приостановлена и возобновлена независимо от основного потока приложения. Это позволяет выполнять код асинхронно, не блокируя основной поток. Легкие потоки являются более легкими и эффективными, чем потоки операционной системы, что делает их подходящими для приложений с большим количеством одновременных задач. Именно этот подход я и хочу обсудить, применительно к нашей прикладной задачи. Отслеживать события способом сопрограмм с обратным вызовом, ну к примере как Вы предлагали сделать общею таблицу событий и ее обрабатывать, удобней наверно даже в виде класса, что можно было масштабироваться и забыть про эту проблематику.
По-моему мнению, Вы ошибаетесь. Если железо одноядерное, то последовательное выполнение - это есть блокирование . При сопрограммах у вас основной поток луа останавливается. иначе это будет параллельное исполнение. Я говорил выше, что сопрограммы это всего диль отдельный стек для луа машины. т е не надо сохранять содержимое основного стека , так как отельный стек не занимается основным потоком. При работе с сопрограммами делается просто переход на другой стек вместо его сохранения и восстановления. Это позволяет прерывать исполнение функций в лбом месте и продолжат их исполнения с этого места. Это все. Но все это последовательно с остановкой всех , кроме одного.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 30.01.2015
22.04.2024 07:00:23
Цитата
VPM написал: , Ну о какой Вы последовательности исполнения говорите, событие или пришло в основную последовательность, забрав на себя исполнение, и сломав последовательность, или не пришло и все исполняется последовательно. На минутку подставим что у нас не одно событие, а отслеживаем несколько? И каждое выскакивает когда вздумается. Похоже нужно дать определения. Но ведь у нас не абстрактные рассуждения мы говорим о луа (а это значить по умолчанию один поток). последовательность исполнения в котором постоянно ломают сопрограммы.
Не соглашусь с Вами. Обычно механизм прерываний по одной из двух схем. 1) Для событий делается очередь. События обрабатываются из очереди. пришло новое , встало в очередь. Если у событий есть приоритет, то оно может прервать выполняемое событие, если оно ниже по приоритету. 2) Пришло событие. Оно блокирует прием новых событий до исполнения этого. ---------------- Обе схемы обеспечивают последовательное выполнение событий. ---------------- Я говорю не абстрактно. Именно так реализуется обработка событий на уровне железа и OC. --------------------- Кораунды это яля потоки на уровне виртуальной машины. Бесспорно, так как железное ядро одно, то все работает последовательно. ----------------------- Если софт написан правильно, то ничего никто не ломает.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 30.01.2015
20.04.2024 18:32:22
Мое понимание сопрограмм такое: ------------------------- Сопрограмма это VMLua, для которой выделен локальный стек в области памяти основной VMLua. ---------------------------- Поэтому у сопрограммы и основной программы общие глобальные переменные и функции. ------------------------- Запуск скрипта как сопрограммы позволяет останавливать выполнение скрипта сопрограммы и не портить локальные параметры функции,которая вызвана как сопрограмма, так как у каждой сопрогаммы свой стек VMLua. ---------------------- Если функцию вызвать без создания сопрограммы, то другая функция может быть запущена лишь по завершению этой, так как они исполняются в одном стеке ---------------------------- Использование сопрограмм не приводит к параллельному вычислению, а лишь позволяет последовательно исполнять функции по частям. -------------------------- В QUIK сопрограмма запущена в отдельном потоке и называется main.
И ещё я вижу торможение, когда окно "Доступные скрипты" располагаю поверх стаканов. В этом случае хорошо видно, что циферки занятости памяти напротив скрипта перерисовываются не мгновенно. Хотя, GPU в диспетчере тоже простаивает, как и CPU. Поэтому я не знаю, как объяснить это торможение. Если перенести это окно на фоновую область окна Квика, то циферки рисуются мгновенно.
Перед началом работы я в диспетчере задач на всякий случай ставлю процессу info.exe высокий приоритет. Но каких-то изменений в связи с этим я не заметил.
Сказать, что конкретно у Вас тормозит не делая лог файлы не реально. ------------------ Могу лишь рассказать результаты моих тестов, которые указывают на то, что КВИК может работать очень быстро. Я выкладывал результаты КРАШ теста, который делал на демо сервере. В тесте я принимал инструменты по колбеку onParam и выставлял на принятый инструмент заявку на покупку в очередь, После подтверждения регистрации заявки на сервере, я отменял ее. В результате 4 часового теста было выставлено и снято более 200 тысяч заявок (это 400 тысяч транзакций) по 200 инструментам. Никаких тормозов я не заметил. Терминал тратил на отправку очередной транзакции не более 0.1 ms. ----------------- После этого теста получил предупреждение от разработчиков, чтобы больше так не грузил их сервер. ------------------------ Поэтому полагаю у Вас может быть либо проблема с Вашим скриптом, либо с Вашим брокером. Сделайте вывод в лог файл в колбеке и в main и сделайте анализ задержек.
339 сделок по одному тикеру в течение 1 мкс
Пользователь
Сообщений: Регистрация: 30.01.2015
19.04.2024 08:26:34
этот механизм брокеры активно использовали раньше для ухода от налогов
написал: Ну например, может оно как-то использует оконные сообщения.
Сомнительно: не видно логики для неработоспособности этой функции в консольных программах. И в документации на сайте МС нет такого предупреждения... Аналогично для более современной функции PlaySound. Как тогда МС вообще планирует использование звука в консольных программах??
Вроде все работает. Попробуйте сделать такую функцию в dll и добавьте sF в таблицу luaL_Reg В данном примере это luaL_Reg nks[]
написал: вот пример сделок по одной цене и время все в пределах 200000 мкс и таких много:
И что? Долбят по мелочи заявку маркетмейкера на миллиард. А потом маркетмейкер решил подвинуться на один пункт и сгреб всех разом...
Время сделки должно совпадать со временем регистрации заявки, вызвавшей эту сделку. Иначе будут вопросы: "Почему по моей заявке сделка прошла по более высокой цене, хотя последняя сделка по низкой цене была на пять микросекунд позже, чем зарегистрирована моя заявка?"
Не соглашусь с Вами. По-моему, маркет мейкер не выставляет очень большие пакеты. ----------------- Я предположил что это сделка РЕПО. ММ эти сделки не делает. РЕПО - это передача акций в долг. Эти сделки делают проф участники между собой.
Нет, ядра у Вас не сильно заняты. Вы можете это увидеть в диспетчере задач. -------------------- У Вас в main используется sleep(1000) т е Вы останавливаете поток Main на 1 секунду. В винде квант, который выделяется задаче составляет 15 ms. У Вас VMLua в потоке работает 1 квант из 60, т е примерно 2% доступного времени.
Почему в этой программке утекает память??
Пользователь
Сообщений: Регистрация: 30.01.2015
18.04.2024 12:34:53
, Чтобы не гонять постоянно сборщик, я создаю таблицы требуемого размера изначально и потом не уничтожаю их. В результате сборщику просто нечего делать.
сборщик мусора в настоящее время используется во многих языках. И основное отличие - алгоритм самой сборки и определение момента сборки. Если кратко, то в луа сборщик контролирует скорость выделение памяти и ее увеличение и в зависимости от этого начинает утилизацию. У вас память растет медленно и мало. Нет смысла запускать сборщик, так как он будет тормозить VMLua. Если памяти на компе достаточно, то его даже вообще отключают. Вы можете поиграть с настройками и подобрать нужный для вас режим сборки.
339 сделок по одному тикеру в течение 1 мкс
Пользователь
Сообщений: Регистрация: 30.01.2015
18.04.2024 12:22:21
и еще... одинаковое время какое-то подозрительное: ...000877
написал: В файлике a1.txt видно, что два рекорда по числу сделок с неизменным временем были не на аукционе открытия. А почему время сделок не меняется, можно только предполагать, а может кто-то, кто сидит ближе к мосбирже, спросит у неё: как объясняется этот феномен?
Я уже предлагал объяснение:
Цитата
Да элементарно. 339 разных заявок в стакане кто-то собрал одной крупной встречной заявкой.
Это же lqdt? Там цена почти не меняется, куча разных заявок стоит в стакане по одной цене. Старый анекдот: Скрытый текст В автобусе: -А вы выходите на следующей? -Да, выхожу. -А люди, которые перед вами, тоже выходят? -Да. Но они об этом еще не знают... Не важно, с какой скоростью сервер обрабатывает транзакции. Все сделки произошли в тот момент, когда прилетела крупная встречная заявка. Но сервер об этом еще не знает - он не успел всё обработать...
Я бы согласился с этой версией, если бы она повторялась. Но такого нет. Да и быть не должно для разных заявок, так как время регистрации заявки - это юридический факт и регистрироваться она должна не в момент прилета большой заявки, а в момент их встречи. Т е если встречные заявки в очереди, то сделки регистрируются последовательно. Ранее давал ссылку на статью, где представитель биржи хвалился что им удалось реализовать 8 сделок в мкс на уровне ядра. В данном случае 339 сделок, т е в 40 раз быстрее. что быть не может для разных биржевых заявок. Объяснить это могу лишь адресной сделкой(заявкой) В ней время сделки будет одно и тоже. вот пример сделок по одной цене и время все в пределах 200000 мкс и таких много:
Код
10:22:39.461441 1.3797 350 B
10:22:39.463233 1.3797 20 B
10:22:39.465084 1.3797 320 B
10:22:39.467713 1.3797 9540 B
10:22:39.469318 1.3797 1 B
10:22:39.470061 1.3797 10 B
10:22:39.472512 1.3797 10 B
10:22:39.474243 1.3797 420 B
10:22:39.486819 1.3797 340 B
10:22:39.508194 1.3797 60 B
10:22:39.513099 1.3797 350 B
10:22:39.515203 1.3797 320 B
10:22:39.516766 1.3797 9540 B
10:22:39.519155 1.3797 10 B
10:22:39.520698 1.3797 20 B
10:22:39.525620 1.3797 10 B
10:22:39.527351 1.3797 420 B
10:22:39.530555 1.3797 340 B
10:22:39.569123 1.3797 60 B
10:22:39.572256 1.3797 350 B
10:22:39.574998 1.3797 10 B
10:22:39.576334 1.3797 20 B
10:22:39.579190 1.3797 10 B
10:22:39.580370 1.3797 420 B
10:22:39.582377 1.3797 270 B
10:22:39.584148 1.3797 9540 B
10:22:39.585802 1.3797 340 B
10:22:39.609057 1.3797 3490 B
10:22:39.614191 1.3797 30 B
10:22:39.619099 1.3797 60 B
10:22:39.625574 1.3797 350 B
10:22:39.628100 1.3797 10 B
10:22:39.629686 1.3797 350 B
10:22:39.638879 1.3797 20 B
10:22:39.645045 1.3797 10 B
10:22:39.646747 1.3797 420 B
10:22:39.648311 1.3797 9540 B
10:22:39.650056 1.3797 340 B
Почему в этой программке утекает память??
Пользователь
Сообщений: Регистрация: 30.01.2015
18.04.2024 08:13:24
Цитата
Serge123 написал: С каждой записью в файл утекает ~ 50 байтов памяти, а почему она не собирается сборщиком мусора??
Код
попробуйте так:
Код
function main ()
for i = 1 , 20 do toFile() sleep ( 1000 ) end
collectgarbage("collect")
end
не хватает только теста под реальной нагрузкой для учёта эффекта синхронизаций
Пока не придумал. Есть варианты алгоритма теста?
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 15:55:00
, Придумал лишь одно объяснение Вашему примеру, где не изменяются ни время ни цена. Это возможно в режиме договорной сделки. Когда через биржу один крупный игрок продает конкретно другому игроку большой объем, например, сделка РЕПО. Но это лишь мое предположение. ------------------
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 15:51:07
Цитата
funduk написал: , ну вот да, поэтому у меня и вопрос, что больше тормозит главный поток квика -- вызов qlua функций из колбэков или из main с синхронизацией. Если число таких вызовов одинаково (что бывает, если main обрабатывает данные быстрее, чем они поступают), должно получиться, что тормозить больше будут вызовы из main, потому что число синхронизаций вырастет. Если же main не успевает за колбэками, и можно не все данные колбэков обрабатывать, то вызов qlua в main может быть быстрее, чем в колбэках, просто потому, что вызовов будет меньше, но накладные расходы на синхронизацию могут всё равно свести преимущество на нет. Поэтому и вопрос был, есть ли у Вас тест на это.
Рассмотрим два варианта В первом колбек читает стаканы и помещаются в очередь их вместе с clas и sec. main читает стаканы из очереди, при этом main еще читает из очереди clas и sec. -------------------- Во втором колбек помещает в очередь clas и sec main читает clas и sec и если надо, то читает стаканы. --------------------- Полагаю, что второй вариант бесспорно лучше. Второй вариант будет еще в разы лучше, если вместо sleep использовать event. -------------------- что не так?
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 13:01:49
, Относительно очистки памяти при выходе из функции или удалении таблицы, ----------------- Сборщик мусора работает по определенному алгоритму у которого есть настраиваемые параметры. ------------------- Чтобы увидеть уменьшение занятой памяти надо запустить сборщик принудительно. пример:
Код
local M=10000000
local t={}
count1 = collectgarbage("count") print("объем занятой памяти",count1//1);
for i=1, M do t[i]=i end
count1 = collectgarbage("count") print("объем занятой памяти массивом",count1//1);
t=nil -- удаляем массив
count1 = collectgarbage("count") print("объем занятой памяти после удаления массива ",count1//1);
collectgarbage("collect") count1 = collectgarbage("count") print("объем занятой памяти после сборщика массива ",count1//1);
os.exit()
результат:
Код
>D:/lua53/lua53.exe -e "io.stdout:setvbuf 'no'" "Test.lua"
объем занятой памяти 58.0
объем занятой памяти массивом 262202.0
объем занятой памяти после удаления массива 262199.0
объем занятой памяти после сборщика массива 50.0
>Exit code: 0
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 12:51:27
и еще... Я как-то выкладывал результаты теста, в котором видно, что колбеки тормозят main поток.
написал: getQuoteLevel2 лучше вызывать в main, чтобы не тормозить основной поток.
У Вас есть какой-нибудь скрипт, подтверждающий это?
Я когда дампил квик через procdump, постоянно видел, что вызовы qlua (типа SetEmptyCallback) из main стояли на входе в критическую секцию, а вот вызовы из главного потока - никогда.
Вес функции qlua в основном стеке. Основной стек в главном потоке. стек main - это дополнительный стек. колбеки блокируют доступ main к глобальному стеку. Поэтому вызов функций qlua в колбеках не требует дополнительной синхронизации. Ее уже сделали при вызове колбека
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
17.04.2024 12:41:16
Цитата
Serge123 написал: Интересно: как можно проверить, что мой вариант скрипта, в котором я перенёс обработку стаканов и обезл. сделок в main, имеет смысл? Мне кажется, что добавилось лишней работы в потоке main с разбором очереди, а в потоке Квика работа уменьшилась неощутимо...
Вы правильно мыслите. Если хотите получить эффект, то надо убирать sleep и использовать event.
написал: getQuoteLevel2 лучше вызывать в main, чтобы не тормозить основной поток.
У Вас есть какой-нибудь скрипт, подтверждающий это?
Я когда дампил квик через procdump, постоянно видел, что вызовы qlua (типа SetEmptyCallback) из main стояли на входе в критическую секцию, а вот вызовы из главного потока - никогда.
Это написано в документации. Могу объяснить на коде почему это так. ----------------- Кроме того, если эта таблица создана глобально, то она будет всегда, если вы явно не присвоите ей nil. ------------------ Проверить можно на СИ. Могу рассказать как.
У Вас время 09:50:00 не содержит микросекунд. Это время Вашего компьютера, а не биржи. Говоря о сделках в 1 мкс Вы очевидно имели ввиду вот это:
Код
9:59:32.000877 1.3796 270 S
09:59:32.000877 1.3796 5 B
09:59:32.000877 1.3796 36 B
09:59:32.000877 1.3796 39689 B
09:59:32.000877 1.3796 11 B
09:59:32.000877 1.3796 5000 B
09:59:32.000877 1.3796 29076 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 200 S
09:59:32.000877 1.3796 1325128 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 25500 S
09:59:32.000877 1.3796 65 S
09:59:32.000877 1.3796 5 B
09:59:32.000877 1.3796 243000 S
09:59:32.000877 1.3796 732 S
09:59:32.000877 1.3796 178 S
09:59:32.000877 1.3796 62 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 210 S
09:59:32.000877 1.3796 3718 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 4 S
09:59:32.000877 1.3796 4063 S
09:59:32.000877 1.3796 5332 S
09:59:32.000877 1.3796 4 S
09:59:32.000877 1.3796 8 S
09:59:32.000877 1.3796 45 S
09:59:32.000877 1.3796 1700 S
09:59:32.000877 1.3796 382 S
09:59:32.000877 1.3796 86 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 803 S
09:59:32.000877 1.3796 10000 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 13000 S
09:59:32.000877 1.3796 395 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 4 S
09:59:32.000877 1.3796 71952 S
09:59:32.000877 1.3796 47 S
09:59:32.000877 1.3796 7 S
09:59:32.000877 1.3796 7 S
09:59:32.000877 1.3796 7 S
09:59:32.000877 1.3796 200 S
09:59:32.000877 1.3796 58 S
09:59:32.000877 1.3796 511 S
09:59:32.000877 1.3796 10 S
09:59:32.000877 1.3796 578 S
09:59:32.000877 1.3796 566 S
09:59:32.000877 1.3796 3000 S
09:59:32.000877 1.3796 39 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 220 S
09:59:32.000877 1.3796 33 S
09:59:32.000877 1.3796 6 S
09:59:32.000877 1.3796 295 S
09:59:32.000877 1.3796 406 B
09:59:32.000877 1.3796 14 B
09:59:32.000877 1.3796 500 B
09:59:32.000877 1.3796 1036 B
09:59:32.000877 1.3796 2242 B
09:59:32.000877 1.3796 9900 B
09:59:32.000877 1.3796 200 B
09:59:32.000877 1.3796 5000 B
09:59:32.000877 1.3796 1000 B
09:59:32.000877 1.3796 21 B
09:59:32.000877 1.3796 65 B
09:59:32.000877 1.3796 330 B
09:59:32.000877 1.3796 55 S
09:59:32.000877 1.3796 20000 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 1244960 S
09:59:32.000877 1.3796 100000 S
09:59:32.000877 1.3796 30000 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 26756 S
09:59:32.000877 1.3796 7000 S
09:59:32.000877 1.3796 1004 S
09:59:32.000877 1.3796 9000 S
09:59:32.000877 1.3796 2233 S
09:59:32.000877 1.3796 10500 S
09:59:32.000877 1.3796 1400 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 150 S
09:59:32.000877 1.3796 59 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 13 S
09:59:32.000877 1.3796 145000 S
09:59:32.000877 1.3796 5000 S
09:59:32.000877 1.3796 1360 S
09:59:32.000877 1.3796 2101 S
09:59:32.000877 1.3796 15 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 11378 S
09:59:32.000877 1.3796 139 S
09:59:32.000877 1.3796 20 S
09:59:32.000877 1.3796 2000 S
09:59:32.000877 1.3796 15135 S
09:59:32.000877 1.3796 110000 S
09:59:32.000877 1.3796 73 S
09:59:32.000877 1.3796 1 S
09:59:32.000877 1.3796 8000 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 1670 S
09:59:32.000877 1.3796 5000 S
09:59:32.000877 1.3796 20000 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 33000 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 12046 S
09:59:32.000877 1.3796 10000 S
09:59:32.000877 1.3796 5000 S
09:59:32.000877 1.3796 10200 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 9510 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 6000 S
09:59:32.000877 1.3796 160000 S
09:59:32.000877 1.3796 1000 S
09:59:32.000877 1.3796 100 S
09:59:32.000877 1.3796 700 S
09:59:32.000877 1.3796 241000 S
09:59:32.000877 1.3796 10320 S
09:59:32.000877 1.3796 87950 S
09:59:32.000877 1.3796 251344 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 2 S
09:59:32.000877 1.3796 615250 S
09:59:32.000877 1.3796 7000 S
09:59:32.000877 1.3796 362845 S
09:59:32.000877 1.3796 168328 S
09:59:32.000877 1.3796 100000 S
09:59:32.000877 1.3796 14873 S
09:59:32.000877 1.3796 493469 S
09:59:32.000877 1.3796 25000 S
09:59:32.000877 1.3796 1200000 S
09:59:32.000877 1.3796 1407296 S
09:59:32.000877 1.3796 181423 S
Обратите внимание, что не изменяются в этих записях время и цена. Т е это не исполнение одной большой заявки по рынку, а продажи большому покупателю, который выставил большой пакет на покупку по фиксированной цене и его обгрызают продавцы. Т е в него стукаются прилетающие заявки. Так делают HFT роботы, но они не могут прилететь все за 1 мкс. Что-то тут не так со временем.
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
16.04.2024 08:50:45
getQuoteLevel2 лучше вызывать в main, чтобы не тормозить основной поток.
До каких пор живёт таблица, передаваемая функции?
Пользователь
Сообщений: Регистрация: 30.01.2015
16.04.2024 08:45:33
Цитата
Serge123 написал: Смутно помнится, в документации на lua.org я видел, что жизнь таблицы из параметров функции гарантируется до выхода из этой функции (т.е. до выхода из OnAllTrade). Какая-то ерунда пока получается с этим переносом обработки таблиц в поток main...
Жизнь локальных параметров прекращается с выходом из функции. А таблица, которую Вы передали через фактические параметры в функцию создана вне этой функции. поэтому она будет утилизирована лишь когда на нее не будет ссылок вообще. Когда вы ее указатель помещаете в очередь, а очередь существует вне функции, то таблица живет своей жизнью и дальше.
написал: Сервер не может провести 339 заявок за 1 мкс.
В 1-м моём сообщении речь шла о сделках. Ошибочно сделки перетекли в заявки...
Суть ответа не меняется. Вы прочитали статьи? Там есть ответ на Ваш вопрос. Поясняю: В вашем вопросе 339 сделок совершено за 1 мкс. Это значит 339 миллионов сделок в секунду . ------------------------- в статье сказано: "8 млн в сек – это внутренняя производительность алгоритма на ядре системы. 50 тыс. – это поток, образуемый клиентской нагрузкой в реальной инфраструктуре – с полным набором компонентов/серверов, резервированием, репликацией, сетевыми устройствами." ------------------------ Т е Ваши 339 это в 40 раз быстрее, чем реально достигнуто на уровне ядра системы на бирже При этом, в системе на момент совершения первой сделки все заявки должны быть уже в очереди(стакане) в оперативной памяти сервера. --------------------
написал: 339 разных заявок в стакане кто-то собрал одной крупной встречной заявкой.
А, ясно, почему такая высокая скорость. А если бы мелкие заявки собирали мелкими, то сервер не успел бы за 1 мкс провести все 339 сделок и образовалась бы очередь?
Сервер не может провести 339 заявок за 1 мкс. это почти миллиард транзакций в секунду. ------------------------ Скорее всего Вы что-то не так поняли. Поэтому и предлагал Вам показать. --------------------- Например, сервер QUIK делает примерно 1000 транзакций в секунду. ---------------------- Делал тест сервера на 4 ядрах. Получил 50 000 транзакций в секунду. -------------------- Сомневаюсь, что на бирже сервер в миллион раз быстрее. --------------------- В вашем случае, сервер биржи должен иметь десятки тысяч ядер .
Альтернатива CanSell/CanBuy
Пользователь
Сообщений: Регистрация: 30.01.2015
13.04.2024 12:07:02
Цитата
Cyber написал: У трех брокеров всегда использовал getBuySellInfo(FIRM_ID,CLIENT_CODE,CLASS_CODE,SEC_CODE,price).can_sell для подсчета возможной позы. И там где не давали шортить can_sell = 0 выдавал. Но тут у БКС выяснилось, что эти значения не соответствуют реальности, и шортить не дают бумаги у которых can_sell не равон нулю. Есть ли в квике какая-то другая таблица с реальными значениями? Откуда еще можно узнать доступную позу?
Запретить шорт по конкретным инструментам и конкретным клиентам - это право брокера . Спросите у брокера список инструментов, которые доступны Вам в шорт.
339 сделок по одному тикеру в течение 1 мкс
Пользователь
Сообщений: Регистрация: 30.01.2015
13.04.2024 12:02:22
Цитата
Serge123 написал: Сегодня наблюдал сабж по некоторой акции на мосбирже с пом. моего скрипта с OnAllTrade. При этом время сделки было то же самое по самую микросекунду. Это произошло сразу после смены цен покупки/продажи. Как такое возможно? Действительно ли эти 339 сделок произошли менее, чем за 1 мкс?
Можно ли где-то получить общее представление о том, как организованы торги на мосбирже и какие там характеристики у серверов (какая ОС, память, ЦП, диски, пропускной канал, ...)? Т.е. как бы совершить виртуальный тур по бирже. Примерно, как в видео на ютюбе о работе tsmc, где клепают лучшие ЦП.
Можете показать фрагмент этих сделок?
Утечка памяти в обработчике SetTableNotificationCallback, Функция обратного вызова обработчика событий пользовательской таблицы не освобождает память между вызовами
Пользователь
Сообщений: Регистрация: 30.01.2015
13.04.2024 11:56:01
Цитата
БорисД написал: Николз может все таки ответишь в этой теме на вопросы заданные тебе ?
А то мы все много раз читали в твоих сообщениях что ты доктор технических наук а каких именно даже в догадках не можем предположить . И про созданный тобой в 1975 году и в одиночку ИИ ( над которым по прежнему бьются все компании программистов мирового уровня ) признайся что это были твои враки , ну типа переборщил ты в самовосхвалении . Иначе дай нам посмотреть на этот твой ИИ от 1975 года выпуска.
Мое сообщение было направлено конкретному человеку. --------------------- Удовлетворять больное любопытство хамов нет желания.
Утечка памяти в обработчике SetTableNotificationCallback, Функция обратного вызова обработчика событий пользовательской таблицы не освобождает память между вызовами
Пользователь
Сообщений: Регистрация: 30.01.2015
12.04.2024 08:41:31
Цитата
Serge123 написал: У меня в связи с выносом обработки в main вопрос: напр., я хочу вынести из OnQuote разбор стакана в main, OnQuote будет вызывать getQuoteLevel2 и запоминать результат в циклический массив, а main будет брать его оттуда по текущему индексу, обрабатывать и освобождать память под эту табличку, которую получила через OnQuote от getQuoteLevel2. Не хочется использовать медленные sinsert и sremove. Можно ли сделать такую схему, чтобы не было конфликтов в связи с параллельным использованием данных между потоком main и потоком коллбэков?
Синхронизируйте работу потоков с этой таблицей. Собственно это и сделано в функциях sinsert и sremove. Чтобы функции работали быстрее, вставляйте в конец и удаляйте последний. Но они работают быстро даже если вставлять и удалять в любое место.
Подскажите с суммирование, Суммирование предыдущего результата
--пусть оценки учеников
local c={2,4,4,4,5,5,7,9}
--тогда среднее
local s=0;
for i=1,#c do s=s+c[i] end s=s/#c; print("s="..s)
--вычислим квадраты отклонения оценок от их средней оценки:
-- и среднее арифметическое этих значений
local s1=0;
for i=1,#c do local x=(c[i]-s)^2; s1=s1+x; end s1=s1/#c; print("s1="..s1)
--стандартное отклонение
local d=math.sqrt(s1); print("d="..d);
, Рыбинкин Не знаю по какой причине Вы решили, что Вам позволено всем хамить. Но это лишь унижает Вас. ================ Вы все хвалитесь своей программой игры в шахматы. А что в этом особенного? ---------------------------- Первая программа игры в шахматы в СССР появилась давно до Вашей. А в период развала СССР (1991) было не до игры в шахматы. ---------------------------- Вы написали свою прогу "мираж" в 1991 году. Я написал программу ИИ в 1975 году. т е за 15 лет до того, как вы научились что-то программировать. -------------------------- Вы получили награду на ВДнХ Я получил 25 авторских на свои изобретения. ---------------------- Вы своей прогой хвалились на ВДНХ. -------------------------- Я свою систему внедрил на трех авиастроительных предприятиях у двух ген.конструкторов и в двух вузах. В трех союзных республиках. =============== Хамство в интернете- это обыденная вещь,поэтому если кто-то мне хамит, я перестаю с ним беседовать. Но обычно такие хамы не затыкаются, так как им важно себя проявлять. ------------------------ Думал, что Вы лишь мне хамите. Но оказалось, что Вы хамите всем. ------------------- Прикольно было почитать в интернете отзывы других о Вашем "авторитете" Вот одна и цитат с форума :
Код
Добавление от 10.02.2006 11:47:Итак, поскольку Владимир решил сдать всё и сразу, мы можем смело зачесть ему высшую оценку в том, к чему он на самом деле стремился - а именно, в доказательстве 4-х тезисов опровергателей:
1. Владимир Рыбинкин ни ухом ни рылом в вопросах, о которых он пытается судить.
2. Владимир Рыбинкин не в состоянии найти в общепризнанных теориях ни единого противоречия.
3. Владимир Рыбинкин не в состоянии свести концы с концами даже в самых основах собственных теорий.
4. Владимир Рыбинкин постоянно вынужден врать и подтасовывать, хотя сам обвиняет в том оппонентов.
Прекрасно раскрыт и доказан также особый "тезис Владимира Рыбинкина", доказываемый лишь меньшинством опровергателей - меньшинством, в котором Владимир занимает выдающееся место:
5. Владимир Рыбинкин не умеет читать, а если чтение ему случайно удаётся, то он не в состоянии понять прочитанное даже после многократного повторения.
Владимир, мои поздравления! Вы отлично справились с доказательствами!
У меня нет иллюзий относительно вас. Хамите дальше, если вы не умеете иначе общаться.
Quik на mac OC Ventura 13.3, Установка Quik на mac под операционной системой Ventura 13.3
Пользователь
Сообщений: Регистрация: 30.01.2015
30.03.2024 11:16:00
Цитата
oldman написал: 0120:fixme:cryptasn:CryptDecodeObjectEx Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.4
вот какой-то рецепт для подобной ошибки:
Код
jkfloris wrote: ↑Fri Feb 03, 2023 4:21 pm
Please check if you have installed the winbind and ttf-mscorefonts-installer packages and try again.CODE: SELECT ALLsudo apt install winbind ttf-mscorefonts-installer
That worked!!! Many many thanks my friend.
----------------
jkfloris написал: ↑Пт 03 февраля 2023 г., 16:21
Пожалуйста, проверьте, установлены ли у вас пакеты winbind и ttf-mscorefonts-installer и попробуйте еще раз.КОД: ВЫБРАТЬ ВСЕ sudo apt install winbind ttf-mscorefonts-installer
--------------------------
Это сработало!!! Большое-большое спасибо, мой друг.
Quik на mac OC Ventura 13.3, Установка Quik на mac под операционной системой Ventura 13.3
Пользователь
Сообщений: Регистрация: 30.01.2015
29.03.2024 19:42:52
на всякий случай в сообщениях написано,хотя и не на русском:
Код
002c:fixme:winediag:loader_init wine-staging 9.1 - это тестовая версия, содержащая экспериментальные исправления.
002c:fixme:winediag:loader_init Пожалуйста, указывайте вашу точную версию при отправке отчетов об ошибках на winehq.org.
0120:исправлено:cryptasn:Неподдерживаемый декодер CryptDecodeObjectEx для lpszStructType 1.3.6.1.4.1.311.2.1.4
0120:исправлено:cryptasn:Неподдерживаемый декодер CryptDecodeObjectEx для lpszStructType 1.3.6.1.4.1.311.2.1.4
Проверка на nil
Пользователь
Сообщений: Регистрация: 30.01.2015
26.03.2024 12:00:59
Код
local x=0;
local t=getFuturesLimit(FIRM, ACCOUNT, 0, "SUR");
if t then x=t.cbplplanned end
Проверка на nil
Пользователь
Сообщений: Регистрация: 30.01.2015
26.03.2024 11:59:24
Код
local t=getFuturesLimit(FIRM, ACCOUNT, 0, "SUR");
local x=t.cbplplanned or 0;
написал: вас так колебет что я повторно написал то, что Вы написали выше?
Переживаю за то, что много мусора на форуме и могут переполниться его база ::
Спите спокойно, товарищ. Эту проблему разработчики решат без нас.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 30.01.2015
19.03.2024 10:07:28
, Все, что Вы повторяете из прочитанных Вами книжек есть лишь пересказ чужих рассуждений. ------ Возможно будет работать, а возможно и нет. ----- Есть еще множество различных рассуждений в подобных книжках. ------------------------ Было бы интересно увидеть результат применения ваших скриптов хотя бы на истории, которая уже есть в КВИКЕ. А написать что-то на луа ,да еще без тестов - это может любой начинающий. ------------------------- Покажите хотя бы какой-нибудь результат. Ну хотя бы советника , который будет иметь положительное мат ожидание сделок хотя бы на истории. ------------------- Уверен, что не получится. Можете доказать иное?
Судя по тому, что вы всегда цитируете сообщения полностью (даже самые длинные), вы, наверное, спамер. Но нельзя исключать с учетом качества выдаваемого вами текста, что вы полуинтеллектуальный робот-спамер :: .
Судя по тому, что вы всегда цитируете сообщения полностью (даже самые длинные), вы, наверное, спамер. Но нельзя исключать с учетом качества выдаваемого вами текста, что вы полуинтеллектуальный робот-спамер :: .
Вы любитель ярлыков? ---------------------- вас так колебет что я повторно написал то, что Вы написали выше? -------------------
