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

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

Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 71 След.
Индикатор уровней High, Low определенной свечи определенного таймфрейма
 
вместо этого:
Код
function OnCalculate(index)
  if (T(index).hour == 16) and (T(index).min == 30) then
    return O(index)  
  end
end
попробуйте так:
Код
function OnCalculate(index) 
local t=T(index);
 if (t.hour == 16) and (t.min == 30) and (t.sec==00) then  x=O(index)  end
return x
end
Почему в этой программке утекает память??
 
Serge123

Возможно Вы знаете, но причина тормозов при отправке заявки может быть из-за  алгоритма Нэгла.
Я его отключал на своем ПК.
Почему в этой программке утекает память??
 
Цитата
Serge123 написал:

И ещё я вижу торможение, когда окно "Доступные скрипты" располагаю поверх стаканов. В этом случае хорошо видно, что циферки занятости памяти напротив скрипта перерисовываются не мгновенно. Хотя, GPU в диспетчере тоже простаивает, как и CPU. Поэтому я не знаю, как объяснить это торможение. Если перенести это окно на фоновую область окна Квика, то циферки рисуются мгновенно.

Перед началом работы я в диспетчере задач на всякий случай ставлю процессу info.exe высокий приоритет. Но каких-то изменений в связи с этим я не заметил.
Сказать, что конкретно у Вас тормозит не делая лог файлы не реально.
------------------  
Могу лишь рассказать результаты моих тестов, которые указывают на то, что КВИК может работать очень быстро.
Я выкладывал результаты КРАШ теста, который делал на демо сервере.
В тесте я принимал инструменты по колбеку onParam и выставлял на принятый инструмент заявку на покупку в очередь,
После подтверждения регистрации заявки на сервере, я отменял ее.
В результате 4 часового теста было выставлено и снято  более 200 тысяч заявок (это 400 тысяч транзакций) по 200 инструментам.
Никаких тормозов я не заметил.
Терминал тратил на отправку очередной транзакции не более 0.1 ms.
-----------------  
После этого теста получил предупреждение от разработчиков, чтобы больше так не грузил их сервер.
------------------------  
Поэтому полагаю у Вас может быть либо проблема с Вашим скриптом, либо с Вашим брокером.
Сделайте вывод в лог файл  в колбеке и в main и сделайте анализ задержек.  
339 сделок по одному тикеру в течение 1 мкс
 
этот механизм брокеры активно использовали раньше для ухода от налогов  
Звук через mciSendString и MessageBeep
 
Цитата
Serge123 написал:
Цитата
paluke написал:
Ну например, может оно как-то использует оконные сообщения.
Сомнительно: не видно логики для неработоспособности этой функции в консольных программах. И в документации на сайте МС нет такого предупреждения... Аналогично для более современной функции PlaySound.
Как тогда МС вообще планирует использование звука в консольных программах??
Вроде все работает.
Попробуйте сделать такую функцию  в dll  и добавьте sF в таблицу luaL_Reg
В данном примере это luaL_Reg nks[]
Код
void WINAPI soundF(char*ps,long m){ PlaySound(ps,GetModuleHandle(NULL), SND_FILENAME|SND_ASYNC);if (m)SleepEx(m,TRUE); }
static int sF(lua_State*L){ soundF((char*)lua_tostring(L,1),lua_tointeger(L,2));return 0; }
в луа надо вызывать так:
Код
local x="C:/Windows/Media/Alarm10.wav" -- звуковой файл
nks.sF(x,1000);
339 сделок по одному тикеру в течение 1 мкс
 
Цитата
paluke написал:
Цитата
nikolz написал:
маркет мейкер не выставляет  очень большие пакеты.
 Это особый случай
Это и есть сделки РЕПО
339 сделок по одному тикеру в течение 1 мкс
 
Цитата
paluke написал:
Цитата
nikolz написал:
вот пример сделок по одной цене и время все в пределах 200000 мкс и таких много:
И что? Долбят по мелочи заявку маркетмейкера на миллиард. А потом маркетмейкер решил подвинуться на один пункт и сгреб всех разом...

Время сделки должно совпадать со временем регистрации заявки, вызвавшей эту сделку. Иначе будут вопросы: "Почему по моей заявке сделка прошла по более высокой цене, хотя последняя сделка по низкой цене была на пять микросекунд позже, чем зарегистрирована моя заявка?"
Не соглашусь с Вами. По-моему, маркет мейкер не выставляет  очень большие пакеты.
-----------------
Я предположил что это сделка РЕПО.  ММ эти сделки не делает.
РЕПО - это передача акций в долг.
Эти сделки делают проф участники между собой.
Почему в этой программке утекает память??
 
Цитата
Serge123 написал:
sleep ( 1000 )
Нет, ядра у Вас не сильно заняты. Вы можете это увидеть в диспетчере задач.
--------------------
У Вас в main используется sleep(1000) т е Вы останавливаете поток Main на 1 секунду.
В винде квант, который выделяется задаче составляет 15 ms.
У Вас VMLua в потоке работает  1 квант из 60, т е примерно 2% доступного времени.  
Почему в этой программке утекает память??
 
Serge123,
Чтобы не гонять постоянно сборщик, я создаю таблицы требуемого размера изначально и потом не уничтожаю их.
В результате сборщику просто нечего делать.
Почему в этой программке утекает память??
 
Цитата
Serge123 написал:
сборщик мусора в настоящее время используется во многих языках. И основное отличие - алгоритм  самой сборки и определение момента сборки.
Если кратко, то в луа сборщик контролирует скорость выделение памяти и ее увеличение и в зависимости от этого начинает утилизацию.
У вас память растет медленно и мало. Нет смысла запускать сборщик, так как он будет тормозить VMLua.
Если памяти на компе достаточно, то его даже вообще отключают.
Вы можете поиграть с настройками и подобрать нужный для вас режим сборки.
339 сделок по одному тикеру в течение 1 мкс
 
и еще...
одинаковое время какое-то подозрительное:  ...000877
339 сделок по одному тикеру в течение 1 мкс
 
Цитата
paluke написал:
Цитата
Serge123 написал:
В файлике 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
Почему в этой программке утекает память??
 
Цитата
Serge123 написал:
С каждой записью в файл утекает ~ 50 байтов памяти, а почему она не собирается сборщиком мусора??
Код
попробуйте так:
Код
 function   main ()
  for  i  =   1 ,  20   do   toFile()   sleep ( 1000 )  end 
collectgarbage("collect")
 end   
339 сделок по одному тикеру в течение 1 мкс
 
Цитата
paluke написал:
Время 09:59:32 намекает, что это  аукцион открытия  
согласен
До каких пор живёт таблица, передаваемая функции?
 
Цитата
funduk написал:
Цитата
nikolz написал:
что не так?
не хватает только теста под реальной нагрузкой для учёта эффекта синхронизаций
Пока не придумал. Есть варианты алгоритма теста?
До каких пор живёт таблица, передаваемая функции?
 
Serge123,
Придумал лишь одно объяснение Вашему примеру, где не изменяются ни время ни цена.
Это возможно в режиме договорной сделки.  
Когда через биржу один крупный игрок продает конкретно другому игроку большой объем, например, сделка РЕПО.
Но это лишь мое предположение.
------------------
До каких пор живёт таблица, передаваемая функции?
 
Цитата
funduk написал:
nikolz, ну вот да, поэтому у меня и вопрос, что больше тормозит главный поток квика -- вызов qlua функций из колбэков или из main с синхронизацией. Если число таких вызовов одинаково (что бывает, если main обрабатывает данные быстрее, чем они поступают), должно получиться, что тормозить больше будут вызовы из main, потому что число синхронизаций вырастет. Если же main не успевает за колбэками, и можно не все данные колбэков обрабатывать, то вызов qlua в main может быть быстрее, чем в колбэках, просто потому, что вызовов будет меньше, но накладные расходы на синхронизацию могут всё равно свести преимущество на нет. Поэтому и вопрос был, есть ли у Вас тест на это.
Рассмотрим два варианта
В первом колбек читает стаканы  и помещаются в очередь их вместе с clas и sec.
main читает стаканы из очереди, при этом main еще читает из очереди clas и sec.
--------------------
Во втором колбек помещает в очередь clas и sec
main  читает clas и sec и  если надо, то читает стаканы.
---------------------
Полагаю, что второй вариант бесспорно лучше.
Второй вариант будет еще в разы лучше,
если вместо sleep использовать event.
--------------------
что не так?
До каких пор живёт таблица, передаваемая функции?
 
Serge123,
Относительно очистки памяти при выходе из функции или удалении таблицы,
-----------------
Сборщик мусора работает по определенному алгоритму у которого есть настраиваемые параметры.
-------------------
Чтобы увидеть уменьшение занятой памяти надо запустить сборщик принудительно.
пример:
Код
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
До каких пор живёт таблица, передаваемая функции?
 
и еще...
Я как-то выкладывал результаты теста, в котором видно, что колбеки тормозят  main поток.
До каких пор живёт таблица, передаваемая функции?
 
Цитата
funduk написал:
Цитата
nikolz написал:
getQuoteLevel2 лучше вызывать в main, чтобы не тормозить основной поток.
У Вас есть какой-нибудь скрипт, подтверждающий это?

Я когда дампил квик через procdump, постоянно видел, что вызовы qlua (типа SetEmptyCallback) из main стояли на входе в критическую секцию, а вот вызовы из главного потока - никогда.
Вес функции qlua в основном стеке.
Основной стек в главном потоке.
стек main - это дополнительный стек.
колбеки блокируют доступ main к  глобальному стеку.
Поэтому вызов функций qlua в колбеках не требует дополнительной синхронизации. Ее уже сделали при вызове колбека  
До каких пор живёт таблица, передаваемая функции?
 
Цитата
Serge123 написал:
Интересно: как можно проверить, что мой вариант скрипта, в котором я перенёс обработку стаканов и обезл. сделок в main, имеет смысл? Мне кажется, что добавилось лишней работы в потоке main с разбором очереди, а в потоке Квика работа уменьшилась неощутимо...
Вы правильно мыслите.
Если хотите получить эффект, то надо убирать sleep и  использовать event.
До каких пор живёт таблица, передаваемая функции?
 
Пардон, ответил не на тот вопрос.
До каких пор живёт таблица, передаваемая функции?
 
Цитата
funduk написал:
Цитата
nikolz написал:
getQuoteLevel2 лучше вызывать в main, чтобы не тормозить основной поток.
У Вас есть какой-нибудь скрипт, подтверждающий это?

Я когда дампил квик через procdump, постоянно видел, что вызовы qlua (типа SetEmptyCallback) из main стояли на входе в критическую секцию, а вот вызовы из главного потока - никогда.
Это написано в документации.
Могу объяснить на коде почему это так.
-----------------
Кроме того, если эта таблица создана глобально, то она будет всегда, если вы явно не присвоите ей nil.
------------------
Проверить можно на СИ.
Могу рассказать как.
339 сделок по одному тикеру в течение 1 мкс
 
Цитата
Serge123 написал:
drive.google.com/file/d/1fbPQM0Xfd-ULQFV7M0vBPW8m_6boaulj/view?usp=sharing
У Вас время  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 мкс.
Что-то тут не так со временем.
До каких пор живёт таблица, передаваемая функции?
 
getQuoteLevel2 лучше вызывать в main, чтобы не тормозить основной поток.
До каких пор живёт таблица, передаваемая функции?
 
Цитата
Serge123 написал:
Смутно помнится, в документации на lua.org я видел, что жизнь таблицы из параметров функции гарантируется до выхода из этой функции (т.е. до выхода из OnAllTrade). Какая-то ерунда пока получается с этим переносом обработки таблиц в поток main...
Жизнь локальных параметров прекращается с выходом из функции.
А таблица, которую Вы передали через фактические параметры в функцию создана вне этой функции.
поэтому она будет утилизирована лишь когда на нее не будет ссылок вообще.
Когда вы ее указатель помещаете в очередь, а очередь существует вне функции, то таблица живет своей жизнью и дальше.
339 сделок по одному тикеру в течение 1 мкс
 
Цитата
Serge123 написал:
Цитата
nikolz написал:
Сервер не может провести 339 заявок за 1 мкс.
В 1-м моём сообщении речь шла о сделках. Ошибочно сделки перетекли в заявки...
Суть ответа не меняется.
Вы прочитали статьи? Там есть ответ на Ваш вопрос.
Поясняю:
В вашем вопросе 339 сделок совершено за 1 мкс. Это значит 339 миллионов сделок в секунду .
-------------------------
в статье сказано:
"8 млн в сек – это внутренняя производительность алгоритма на ядре системы.
50 тыс. – это поток, образуемый клиентской нагрузкой в реальной инфраструктуре
– с полным набором компонентов/серверов, резервированием, репликацией, сетевыми устройствами."
------------------------
Т е Ваши 339 это в 40 раз быстрее, чем реально достигнуто на уровне ядра системы на бирже
При этом, в системе на момент совершения первой сделки все заявки должны быть уже в очереди(стакане)
в оперативной памяти сервера.
--------------------  
339 сделок по одному тикеру в течение 1 мкс
 
ликбез:
почитайте это:
https://habr.com/ru/companies/moex/articles/444300/
https://habr.com/ru/companies/moex/articles/444302/
339 сделок по одному тикеру в течение 1 мкс
 
Цитата
Serge123 написал:
Цитата
paluke написал:
339 разных заявок в стакане кто-то собрал одной крупной встречной заявкой.
А, ясно, почему такая высокая скорость. А если бы мелкие заявки собирали мелкими, то сервер не успел бы за 1 мкс провести все 339 сделок и образовалась бы очередь?
Сервер не может провести 339 заявок за 1 мкс. это почти миллиард транзакций в секунду.
------------------------
Скорее всего Вы что-то не так поняли. Поэтому и предлагал Вам показать.
---------------------
Например, сервер QUIK делает примерно 1000 транзакций в секунду.
----------------------
Делал тест сервера на 4 ядрах. Получил 50 000 транзакций в секунду.
--------------------
Сомневаюсь, что на бирже сервер в миллион раз быстрее.
---------------------
В вашем случае, сервер биржи должен иметь десятки тысяч ядер .
 
Альтернатива CanSell/CanBuy
 
Цитата
Cyber написал:
У трех брокеров всегда использовал
getBuySellInfo(FIRM_ID,CLIENT_CODE,CLASS_CODE,SEC_CODE,price).can_sell
для подсчета возможной позы.
И там где не давали шортить can_sell = 0 выдавал.
Но тут у БКС выяснилось, что эти значения не соответствуют реальности, и шортить не дают бумаги у которых can_sell не равон нулю.
Есть ли в квике какая-то другая таблица с реальными значениями? Откуда еще можно узнать доступную позу?
Запретить шорт по конкретным инструментам  и конкретным клиентам - это право брокера .
Спросите у брокера список инструментов, которые доступны Вам в шорт.
339 сделок по одному тикеру в течение 1 мкс
 
Цитата
Serge123 написал:
Сегодня наблюдал сабж по некоторой акции на мосбирже с пом. моего скрипта с OnAllTrade. При этом время сделки было то же самое по самую микросекунду. Это произошло сразу после смены цен покупки/продажи. Как такое возможно? Действительно ли эти 339 сделок произошли менее, чем за 1 мкс?

Можно ли где-то получить общее представление о том, как организованы торги на мосбирже и какие там характеристики у серверов (какая ОС, память, ЦП, диски, пропускной канал, ...)? Т.е. как бы совершить виртуальный тур по бирже. Примерно, как в видео на ютюбе о работе tsmc, где клепают лучшие ЦП.
Можете показать фрагмент этих сделок?  
Утечка памяти в обработчике SetTableNotificationCallback, Функция обратного вызова обработчика событий пользовательской таблицы не освобождает память между вызовами
 
Цитата
БорисД написал:
Николз может все таки ответишь в этой теме на вопросы заданные тебе ?   https://forum.quik.ru/messages/forum10/message75159/topic8528/#message75159

А то мы все много раз читали в твоих сообщениях что ты  доктор технических наук а каких именно даже в догадках не можем  предположить . И про созданный тобой  в 1975 году и  в одиночку ИИ ( над которым по прежнему бьются все компании программистов мирового уровня )  признайся что это были твои враки , ну типа переборщил ты в самовосхвалении .  Иначе дай нам посмотреть на этот твой ИИ от 1975 года выпуска.  
Мое сообщение было направлено конкретному человеку.
---------------------
Удовлетворять больное любопытство хамов нет желания.
Утечка памяти в обработчике SetTableNotificationCallback, Функция обратного вызова обработчика событий пользовательской таблицы не освобождает память между вызовами
 
Цитата
Serge123 написал:
У меня в связи с выносом обработки в main вопрос: напр., я хочу вынести из OnQuote разбор стакана в main, OnQuote будет вызывать getQuoteLevel2 и запоминать результат в циклический массив, а main будет брать его оттуда по текущему индексу, обрабатывать и освобождать память под эту табличку, которую получила через OnQuote от getQuoteLevel2. Не хочется использовать медленные sinsert и sremove. Можно ли сделать такую схему, чтобы не было конфликтов в связи с параллельным использованием данных между потоком main и потоком коллбэков?
Синхронизируйте работу потоков с этой таблицей.  Собственно это и сделано в функциях sinsert и sremove.
Чтобы функции работали быстрее, вставляйте в конец и удаляйте последний.  
Но они работают быстро даже если вставлять и удалять в любое место.
Подскажите с суммирование, Суммирование предыдущего результата
 
Цитата
Phil написал:
Пример по прикрепленному ранее файлу
Код
--пусть оценки учеников
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);
результат:
Код
>D:/lua53/lua53.exe -e "io.stdout:setvbuf 'no'" "test_SMA.lua" 
s=5.0
s1=4.0
d=2.0
>Exit code: 0
dll на C: удивительная ошибка...
 
Владимир,  Рыбинкин
Не знаю по какой причине Вы решили, что Вам позволено всем хамить.
Но это лишь унижает Вас.
================
Вы все хвалитесь своей программой игры в шахматы.
А что в этом особенного?
----------------------------
Первая программа игры в шахматы в СССР появилась давно до Вашей.
А в период развала СССР (1991) было не до игры в шахматы.
----------------------------
Вы написали свою прогу "мираж" в 1991 году.
Я написал программу ИИ в 1975 году.  
т е за 15 лет до того, как вы научились что-то программировать.
--------------------------
Вы получили награду на ВДнХ
Я получил 25 авторских на свои изобретения.
----------------------
Вы своей прогой хвалились на ВДНХ.
--------------------------
Я свою систему внедрил на трех авиастроительных предприятиях у двух ген.конструкторов
и в двух вузах. В трех союзных республиках.
===============
Хамство в интернете- это обыденная вещь,поэтому  если кто-то мне хамит, я перестаю с ним беседовать.
Но обычно такие хамы не затыкаются, так как им важно себя проявлять.
------------------------
Думал, что Вы лишь мне хамите.
Но оказалось, что Вы хамите всем.
-------------------
Прикольно было почитать в интернете отзывы других о Вашем "авторитете"
Вот одна и цитат с форума  https://forum.ixbt.com/topic.cgi?id=64:238-110
:
Код
Добавление от 10.02.2006 11:47:Итак, поскольку Владимир решил сдать всё и сразу, мы можем смело зачесть ему высшую оценку в том, к чему он на самом деле стремился - а именно, в доказательстве 4-х тезисов опровергателей:

1. Владимир Рыбинкин ни ухом ни рылом в вопросах, о которых он пытается судить.
2. Владимир Рыбинкин не в состоянии найти в общепризнанных теориях ни единого противоречия.
3. Владимир Рыбинкин не в состоянии свести концы с концами даже в самых основах собственных теорий.
4. Владимир Рыбинкин постоянно вынужден врать и подтасовывать, хотя сам обвиняет в том оппонентов.

Прекрасно раскрыт и доказан также особый "тезис Владимира Рыбинкина", доказываемый лишь меньшинством опровергателей - меньшинством, в котором Владимир занимает выдающееся место:

5. Владимир Рыбинкин не умеет читать, а если чтение ему случайно удаётся, то он не в состоянии понять прочитанное даже после многократного повторения.

Владимир, мои поздравления! Вы отлично справились с доказательствами!

У меня нет иллюзий относительно вас.
Хамите дальше, если вы не умеете иначе общаться.  
Quik на mac OC Ventura 13.3, Установка Quik на mac под операционной системой Ventura 13.3
 
Цитата
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
 
на всякий случай в сообщениях написано,хотя и не на русском:
Код
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
 
Код
local x=0;
local t=getFuturesLimit(FIRM, ACCOUNT, 0, "SUR");
if t then x=t.cbplplanned end 
Проверка на nil
 
Код
local t=getFuturesLimit(FIRM, ACCOUNT, 0, "SUR");
local x=t.cbplplanned or 0; 
Повторное использование строки
 
Цитата
TGB написал:
Цитата
nikolz написал:
вас так колебет что я повторно написал то, что Вы написали выше?
   Переживаю за то, что много мусора на форуме и могут переполниться его база ::
Спите спокойно, товарищ.
Эту проблему разработчики решат без нас.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
VPM,
Все, что Вы повторяете из прочитанных Вами книжек есть лишь пересказ чужих рассуждений.
------
Возможно будет работать, а возможно и нет.
-----
Есть еще множество различных рассуждений в  подобных книжках.
------------------------
Было бы интересно увидеть результат применения ваших скриптов хотя бы на истории,
которая уже есть в КВИКЕ.
А написать что-то на луа ,да еще без тестов - это может любой начинающий.
-------------------------
Покажите хотя бы какой-нибудь результат.
Ну хотя бы советника , который будет иметь положительное мат ожидание сделок хотя бы на истории.
-------------------
Уверен, что не получится.
Можете доказать иное?
Повторное использование строки
 
Цитата
TGB написал:
Цитата
nikolz написал:
А вы догадайтесь.
    Судя по тому, что вы всегда цитируете сообщения полностью (даже самые длинные), вы, наверное, спамер. Но нельзя исключать с учетом качества выдаваемого вами текста, что вы полуинтеллектуальный робот-спамер :: .
Попробуйте не вешать ярлыки, а спорить предметно.
Повторное использование строки
 
Цитата
TGB написал:
Цитата
nikolz написал:
А вы догадайтесь.
    Судя по тому, что вы всегда цитируете сообщения полностью (даже самые длинные), вы, наверное, спамер. Но нельзя исключать с учетом качества выдаваемого вами текста, что вы полуинтеллектуальный робот-спамер :: .
Вы любитель ярлыков?
----------------------
вас так колебет что я повторно написал то, что Вы написали выше?
-------------------
Если бы я был архитектором QUIK, Что стоило бы изменить в QUIK по-крупному
 
вот тут можете посмотреть варианты как делать очередь.
И результаты тестов различных вариантов.
https://forum.quik.ru/forum17/topic8426/
---------------
С интересом посмотрю Ваши результаты решений.
Может обсудить конкретные решение, что будет полагаю интересно начинающим.
Если бы я был архитектором QUIK, Что стоило бы изменить в QUIK по-крупному
 
Вы тоже не читаете внимательно чужие предложения.
Я на форуме не только предлагал, но и показывал как это работает у меня.
-------------------
Например, я выполнение различных алгоритмов обработки событий реализую не только на Lua, но и на Luajit ( что более чем на порядок быстрее)
на Terra, на Python, на julia.  
Если бы я был архитектором QUIK, Что стоило бы изменить в QUIK по-крупному
 
TGB,
Про колебки Вы пишите фигню.
Колбеки не запускаются, а вызываются.
------------------------
Никто не мешает Вам запустить в колбеке новый поток.
--------------
Я это использую уже давно.
Об это писал у же на форуме.
Если бы я был архитектором QUIK, Что стоило бы изменить в QUIK по-крупному
 
Цитата
TGB написал:
2.  
Цитата
nikolz написал:
 TGB  ,
Sleep - это функция, которая останавливает поток и возвращает управление OC.
Что Вы будете модифицировать в ней?
 Опять, та же фигня :: .  
Я пишу про sleep (это функция QLua):
Цитата
Фигня это у Вас.
sleep в QLua - это обертка для Sleep OC.
Поэтому Ваше рассуждение про "модификацию" - это пустая фраза.
Повторное использование строки
 
Цитата
TGB написал:
Цитата
nikolz написал:
Если Вы это сообщение выводите в файл, то пишите сразу в файл. куски сообщения. Каждый новый кусок добавится в конец файлаВ итоге Вам не надо наращивать строки.
   nikolz писатель?  
  Зачем вы пишите, то что было уже написано два раза?:
1)  
Цитата
TGB написал:
Почему бы не записывать строку сразу в файл (в системе это буферизуется). Вы проверяли, сколько записей выполняется в файл за 1 секунду, если писать напрямую? Если вы это сделаете, то, возможно, удивитесь.
2)  
Цитата
Nikolay написал:
У меня такие потоки для каждой новой записи просто пишутся в файл черезf:write(str..'\n')
   Вы так спамите или не умеете читать :: ?
А вы догадайтесь.
Повторное использование строки
 
Цитата
Serge123 написал:
Как-то уже об этом писал...
Есть строка mess (age), в которой коллбэки накапливают свой вывод, при превышении определённой длины строка записывается в файл. Потом обычно пишут mess='', чтобы сбросить длину строки в 0, но что в этом случае произойдёт? Создастся новая строка, или в структуре TString для этой строки её длина установится в 0?
Я не вижу, где хранится число байтов, выделенных под строку, и как контролируется выход за её предел при дописывании к строке?
Не хочется ненужного пересоздания строки и сборки мусора, а хочется просто зарезервировать под строку 10 Мб и использовать эту же память под строку постоянно. Зачем выметать сор из  избы  строки, если можно обойтись без этого? Как это всё оптимизировать и сделать, как в нормальных языках типа того же си?
Если Вы это сообщение выводите в файл, то пишите сразу в файл. куски сообщения.
Каждый новый кусок добавится в конец файла
В итоге Вам не надо наращивать строки.
Если бы я был архитектором QUIK, Что стоило бы изменить в QUIK по-крупному
 
TGB,
Sleep - это функция, которая останавливает поток и возвращает управление OC.
Что Вы будете модифицировать в ней?
Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 71 След.
Наверх