Тайминг функциональности QUIK из луа

Страницы: 1 2 След.
RSS
Тайминг функциональности QUIK из луа, как правильно замерить
 
Попробовал гонять кое - какие тесты скорости своего скрипта.
Один из тестов пытался отределить время затрачиваемое непосредственно на системный вызов getQuoteLevel2
Код
local TheClassCode = "QJSIM"
local TheSecCode = "SBER"
local NumIteractions2 = 100000
local NumRepeats2 = 10
local StartTime = 0
local RunTime = 0
local SumRunTime = 0
local MaxRunTime = 0
local MinRunTime = 100500
local QuoteL2 = {}

function TestQuoteL2_2()
    for TheRepeat =1, NumRepeats2, 1    do
        StartTime = os.clock()

        for TheIteraction =1, NumIteractions, 1 do
            QuoteL2 = getQuoteLevel2(TheClassCode, TheSecCode)
        end

        RunTime = os.clock() - StartTime
        SumRunTime = SumRunTime + RunTime
        if RunTime < MinRunTime then
            MinRunTime = RunTime
        end
        if RunTime > MaxRunTime then
            MaxRunTime = RunTime
        end
        TheMessage = "Attempt # "..tostring(TheRepeat).." RunTime = "..tostring(RunTime)
        message(TheMessage)
    end
    local AvgRunTime = SumRunTime / NumRepeats2
    TheMessage = "Tested "..tostring(NumRepeats2).." times, "..tostring(NumIteractions2).." iteractions each"
    message(TheMessage)
    TheMessage = "Average run time = "..tostring(AvgRunTime).." for "..tostring(NumIteractions2).." iteractions"
    message(TheMessage)
    TheMessage = "Maximum run time = "..tostring(MaxRunTime)
    message(TheMessage)
    TheMessage = "Minimum run time = "..tostring(MinRunTime)
    message(TheMessage)
end

function main()
    TestQuoteL2_2()
end
Это фрагмент разумеется, полный текст там слишком много букв для цитирования да и к вопросу отношения не имеет, еще ряд тестов уже моего кода. Так вот, результат работы этого конкретно теста:
Код
08.10.2018    0:15:42    Tested 10 times, 100000 iteractions each
08.10.2018    0:15:42    Average run time = 8.3163 for 100000 iteractions
08.10.2018    0:15:42    Maximum run time = 8.3400000000001
08.10.2018    0:15:42    Minimum run time = 8.2939999999999
В связи с тем что время вызова самой функции getQuoteLevel2 у меня получилось чуть ли не на порядок больше времени которое требуется моему скрипту на парсинг полученой таблицы (речь идет о стакане 10х10, для имитации деятельности осуществлялся двукратный доступ ко всем содержательнм полям) возник у меня вопрос.
Подскажите пожалуйста, порректно ли вообще измерять время на вызов функций квик подобным способом. Или "дерганье" их миллион раз подряд вызывает какие-то аномалии в работе квик?
 
Цитата
BlackBoar написал:
Подскажите пожалуйста, порректно ли вообще измерять время на вызов функций квик подобным способом. Или "дерганье" их миллион раз подряд вызывает какие-то аномалии в работе квик?
"дерганье" миллион раз не должно вызывать никаких аномалий.
Другой вопрос в том что каждая итерация цикла может выполняться раз в 15.625 мс, почитать можно например тут: https://habrahabr.ru/company/intel/blog/186998/
 
Цитата
Sergey Gorokhov написал:
"дерганье" миллион раз не должно вызывать никаких аномалий.Другой вопрос в том что каждая итерация цикла может выполняться раз в 15.625 мс, почитать можно например тут:  https://habrahabr.ru/company/intel/blog/186998/
Во-первых спасибо за консультации.

Далее, закрыл Visual Studio. ))) Убедился что таймер на умолчательных 15.6, повторил тесты. Результат лучше на ~17%
Стакан 10х10 в диапазоне 65-73 микросекунды, стакан 20х20 125-135 микросекунд. Вопрос, похожи ли эти цифры на то что быть должно или следует искать еще узкие места?
 
Апдейт, поэкспериментировал разворачивать цикл чтобы было меньше итераций самого цикла.

Лучший результат для стакана 10х10 где-то 55-65 микросекунд. Когда внутри цикла больше 100 строк кода похоже растут накладные расходы самого луа-движка, дальнейшее разворачивание уже ухудшает результат.
Вопрос тот же, цифры уже похожи на то из чего можно исходить?
 
Цитата
BlackBoar написал:
Апдейт, поэкспериментировал разворачивать цикл чтобы было меньше итераций самого цикла.
Лучший результат для стакана 10х10 где-то 55-65 микросекунд. Когда внутри цикла больше 100 строк кода похоже растут накладные расходы самого луа-движка, дальнейшее разворачивание уже ухудшает результат.
Вопрос тот же, цифры уже похожи на то из чего можно исходить?
Боюсь что на этот вопрос нет ответа. Т.к. нет такого эталонного образца "то что должно быть"
 
Цитата
Sergey Gorokhov написал:
Боюсь что на этот вопрос нет ответа. Т.к. нет такого эталонного образца "то что должно быть"
Чисто любопытства ради попробую сформулировать вопрос по другому.
В стакане NxN очевидно 4N содержательных цифр. Мой тестовый код имитирующий работу со стаканом получает каждую, умножает на какое-то число с плавающей точкой (сишный double), далее складывает с каким-то числом с плавающей точкой и потом сравнивает с еще каким-то числом с плавающей точкой. По результатам сравнения инкрементируется один из двух счетчиков.
Так вот, вся эта активность занимает примерно в 400 раз меньше времени чем получение стакана. Такое соотношение выглядит нормально?

И еще вопрос по близкой теме. Глубину получения стаканов можно менять в настройках квик. А из скрипта луа есть аналогичная функциональность? И если нет можно ли выразить пожелание ее добавить?
 
Конечно нормально. Исходим из того, что вы правильно поменяли время и сделали верные расчеты.

ваш запрос к терминалу на получение стакана ставится в терминале в очередь на обработку. И наверняка с низким приоритетом.

сначала выполняются важные для терминала действия, а потом уже дело доходит и до вашего скрипта.
 
Цитата
BlackBoar написал:
И еще вопрос по близкой теме. Глубину получения стаканов можно менять в настройках квик. А из скрипта луа есть аналогичная функциональность? И если нет можно ли выразить пожелание ее добавить?

Из скрипта Lua вообще нет никакой штатной возможности менять какие-либо настройки терминала.
 
Ситуация более-менее понятна, благодарю за ответы!
Буду думать дальше )))
 
Цитата
s_mike@rambler.ru написал:
ваш запрос к терминалу на получение стакана ставится в терминале в очередь на обработку. И наверняка с низким приоритетом.
Кстати. Я на самом деле не могу ничего возразить ибо понятия не имею что в недрах терминала происходит.
Но вот тот факт что время отклика почти прямо пропорционально размеру стакана наводит на мысль что основные накладные расходы таки при его формировании.
Мысль неконструктивная, способа послиять на формирование стакана не видно. Просто любопытно.
 
Цитата
BlackBoar написал:
Цитата
   s_mike@rambler.ru написал:
ваш запрос к терминалу на получение стакана ставится в терминале в очередь на обработку. И наверняка с низким приоритетом.
Кстати. Я на самом деле не могу ничего возразить ибо понятия не имею что в недрах терминала происходит.
Но вот тот факт что время отклика почти прямо пропорционально размеру стакана наводит на мысль что основные накладные расходы таки при его формировании.
Мысль неконструктивная, способа послиять на формирование стакана не видно. Просто любопытно.
относительно стакана могу предположить следующее
Так как данные стакана с биржи передаются в виде изменений стакана, то в терминале стакан хранится очевидно в виде списка.
Вот из этого списка и формируется таблица луа.
--------------------------
Ваши замеры близки к истине. Попробуйте еще измерить для сравнения время пустого цикла на луа
-----------------------
Но эти замеры мало что дают для оценки быстродействия робота.
Проблема в том что данные с сервера QUIK приходят блоками в которых собирается инфа за некоторое время.
Возникает вопрос на сколько реально полученные данные запаздывают от их появления на бирже.
Собственно успешность HFT робота и зависит от этого запаздывания.
Попробуйте оценить это время и сравнить его со скоростью обработки полученных данных.
 
Цитата
Николай Камынин написал:
Попробуйте еще измерить для сравнения время пустого цикла на луа
В моих условиях ничего познавательного. Флуктуации вокруг нуля если можно так позволить себе выразиться. Придумал другой замер:
Код
size_t iResult;
lua_settop(L, 0);
lua_getfield(L, LUA_GLOBALSINDEX, "getQuoteLevel2");
lua_pushstring(L, pcClassCode);
lua_pushstring(L, pcSecCode);
iResult = lua_pcall(L, 2, 1, NULL);  // Здесь все накладные расходы
if (iResult)
{
   // Сюда я ни разу не попадал
}
else
{
  // А здесь я имитирую полезную деятельность
}
lua_settop(L, 0);
Итого, lua_pcall - порядка 99.1 - 99.3% всего времени, остальные луа - вызовы порядка 0.4%, моя деятельность 0.25-0.5%
Собственно подтверждает все те же мысли.

Цитата
Николай Камынин написал:
Но эти замеры мало что дают для оценки быстродействия робота.Проблема в том что данные с сервера QUIK приходят блоками в которых собирается инфа за некоторое время.Возникает вопрос на сколько реально полученные данные запаздывают от их появления на бирже.Собственно успешность HFT робота и зависит от этого запаздывания.Попробуйте оценить это время и сравнить его со скоростью обработки полученных данных.
Дык понятно что крутым высокочастотником я при использовании квика не стану. Смысл замера в другом, если связываться работать со стаканами вообще - буду иметь представление о пропускной способности. И не создам сам себе узких мест. Постараюсь во всяком случае )))
 
Возник еще вопрос по близкой в принципе теме, поэтому подниму эту.
Допустим, есть СкриптА, торгует Si, и СкриптБ, торгует сбером. В каждом своя функция main исполняющаяся в своем потоке windows. В какой-то момент функция мэйн СкриптА вызывает getQuoteLevel2("SPBFUT", "SiZ8"). Стакан у брокера 50х50, соответственно вызов (для моего компа) будет исполняться 300+ микросекунд. Через микросекунду функция мэйн в СкриптБ выдает вызов getQuoteLevel2("TQBR", "SBER").

Что будет далее, СкриптБ будет стоять пока исполняется вызов из СкриптА или что-то еще?

Доп1: На getQuoteLevel2 свет клином естественно не сходился, взял ее же для примера потому что она одна из самых "долгих". Вопрос разумеется по ситуации с потоками вообще.
Доп2: То что ситуация в примере говорит о неважном проектировании и вообще намекает на склонность к дерьмокодерству в курсе, опять же просто пример придумал на скорую руку )))
 
Цитата
BlackBoar написал:
Что будет далее, СкриптБ будет стоять пока исполняется вызов из СкриптА или что-то еще?

ничего не будет.
 
Цитата
Sergey Gorokhov написал:
ничего не будет.
Не понял, я невнятно сформулировал вопрос или эта тема табу.
Будет  либо последовательное выполнение запросов либо параллельное (при  наличии свободных процессорных ядер разумеется). "Ничего" быть не может  раз уж скрипты вообще работают. Я разумеется могу рано или поздно  протестировать сам, но был уверен что поддержка знает ответ. Странно както, при все уважении....
 
Цитата
BlackBoar написал:
Цитата
Sergey Gorokhov написал:
ничего не будет.
Не понял, я невнятно сформулировал вопрос или эта тема табу.
Будет  либо последовательное выполнение запросов либо параллельное (при  наличии свободных процессорных ядер разумеется). "Ничего" быть не может  раз уж скрипты вообще работают. Я разумеется могу рано или поздно  протестировать сам, но был уверен что поддержка знает ответ. Странно както, при все уважении....
"Ничего не будет" означает что в описанном сценарии скрипты не будут друг другу мешать.
Вы можете самостоятельно протестировать и убедиться в этом
 
Цитата
Sergey Gorokhov написал:
"Ничего не будет" означает что в описанном сценарии скрипты не будут друг другу мешать.Вы можете самостоятельно протестировать и убедиться в этом
Благодарю, именно это и хотел узнать не занимаясь разработкой очередного теста и размышлениями о его адекватности )))
 
Добрый день.
1. Всех - "с наступающим".
2. Учитывая вышеписанное ("Итого, lua_pcall - порядка 99.1 - 99.3% всего времени" ... напомню, call была -- getQuoteLevel2), а также учитывая, что в подавляющем большинстве запросов стакан отличается от предыдущего не более, чем на 15%(а то и -- гораздо менее),
а также учитывая, что нормальный API нам АRQA никогда не предоставит,
Прошу зарегистрировать пожелание по развитию QUIK, а именно
Cделать в Qlua функцию, альтернативную getQuoteLevel2,
Которая будет передавать массив ТОЛЬКО ИЗМЕНЕННЫХ строк в стакане.
 
Цитата
PFelix написал:
Добрый день.
1. Всех - "с наступающим".
2. Учитывая вышеписанное ("Итого, lua_pcall - порядка 99.1 - 99.3% всего времени" ... напомню, call была -- getQuoteLevel2), а также учитывая, что в подавляющем большинстве запросов стакан отличается от предыдущего не более, чем на 15%(а то и -- гораздо менее),
а также учитывая, что нормальный API нам АRQA никогда не предоставит,
Прошу зарегистрировать пожелание по развитию QUIK, а именно
Cделать в Qlua функцию, альтернативную getQuoteLevel2,
Которая будет передавать массив ТОЛЬКО ИЗМЕНЕННЫХ строк в стакане.
Здравствуйте,
К сожалению данное пожелание не может быть реализовано т.к. стаканы транслируются срезами.
Т.е. получив очередной срез стакана мы не можем никак узнать какие строки действительно изменились, а какие остались в прежнем состоянии.
И проблема не в QLUA и не в самом QUIK, сама биржа так транслирует данные.
 
Добрый день.
Сергей, я правильно Вас понял, что биржа (вероятно, всё-таки сервер QUIK) транслирует стакан каждый раз ПОЛНОСТЬЮ?
 
Цитата
PFelix написал:
Добрый день.
Сергей, я правильно Вас понял, что биржа (вероятно, всё-таки сервер QUIK) транслирует стакан каждый раз ПОЛНОСТЬЮ?

Стаканы транслируются биржей каждый раз полностью.
 
best essay writing service
write my essay

viagra generic viagra generic
viagra for sale viagra for sale
levitra 20 mg levitra 20 mg
viagra for sale viagra for sale
write my essay write my essay
custom writing custom writing
viagra generic viagra generic
essay writing service essay writing service
viagra without a doctor prescription viagra without a doctor prescription
write my paper
essay writing service
 
writing help
custom writing

viagra generic viagra generic
viagra for sale viagra for sale
levitra 20 mg levitra 20 mg
viagra for sale viagra for sale
write my essay write my essay
custom writing custom writing
viagra generic viagra generic
essay writing service essay writing service
viagra without a doctor prescription viagra without a doctor prescription
write my paper
best essay writing service
 
paper writing service
write my paper

viagra generic viagra generic
viagra for sale viagra for sale
levitra 20 mg levitra 20 mg
viagra for sale viagra for sale
write my essay write my essay
custom writing custom writing
viagra generic viagra generic
essay writing service essay writing service
viagra without a doctor prescription viagra without a doctor prescription
best essay writing service
custom writing
 
paper writing service
write my essay

viagra generic viagra generic
viagra for sale viagra for sale
levitra 20 mg levitra 20 mg
viagra for sale viagra for sale
write my essay write my essay
custom writing custom writing
viagra generic viagra generic
essay writing service essay writing service
viagra without a doctor prescription viagra without a doctor prescription
write my essay
write my paper
 
essay help
custom writing

viagra generic viagra generic
viagra for sale viagra for sale
levitra 20 mg levitra 20 mg
viagra for sale viagra for sale
write my essay write my essay
custom writing custom writing
viagra generic viagra generic
essay writing service essay writing service
viagra without a doctor prescription viagra without a doctor prescription
write my paper
essay writing service
 
write my essay
write my essay for me

viagra generic viagra generic
viagra for sale viagra for sale
levitra 20 mg levitra 20 mg
viagra for sale viagra for sale
write my essay write my essay
custom writing custom writing
viagra generic viagra generic
essay writing service essay writing service
viagra without a doctor prescription viagra without a doctor prescription
write my paper for me
write my essay for me
 
Понятно, спасибо.
Однако, не понятно, почему нельзя сохранять предыдущий стакан (его состояние) и с ним сравнивать текущий.
На нативной стороне это гораздо быстрее. После чего на сторону LUA отдавать только строки с измененным количеством лотов.
 
write my paper for me
paper writing service

viagra generic viagra generic
viagra for sale viagra for sale
levitra 20 mg levitra 20 mg
viagra for sale viagra for sale
write my essay write my essay
custom writing custom writing
viagra generic viagra generic
essay writing service essay writing service
viagra without a doctor prescription viagra without a doctor prescription
write my paper for me
essay writing service
 
Цитата
PFelix написал:
Понятно, спасибо.
Однако, не понятно, почему нельзя сохранять предыдущий стакан (его состояние) и с ним сравнивать текущий.
На нативной стороне это гораздо быстрее. После чего на сторону LUA отдавать только строки с измененным количеством лотов.

Потому что нет никакой возможности определить что строка изменилась, в случае если визуально она не изменилась.

Банальный пример, цена между двумя срезами скакнула и вернулась в то же состояние что и на первом срезе.
Изменение было? да было.
Но визуально ничего не поменялось.
И как это отличить от случая когда ничего не поменялось?
Никак.
 
Вот и славно.
Калбек придет -- мы будем знать, что изменение было.
А функция вернет пустую таблицу (или вообще nil или bid_count и offer_count = 0).
Результат достигнут,  -- время на построение LUA-таблиц при вызове альтернативной  функции многократно сократится.
 
Цитата
PFelix написал:
Вот и славно.
Калбек придет -- мы будем знать, что изменение было.
А функция вернет пустую таблицу (или вообще nil или bid_count и offer_count = 0).
Результат достигнут,  -- время на построение LUA-таблиц при вызове альтернативной  функции многократно сократится.

Кажется Вы не поняли о чем речь.
Вы же сами сказали что надо отловить изменения.
допустим были изменения в лучшем bid
1200 <- попал в срез
1201 <- НЕ попал в срез
1200 <- попал в срез

В Вашем примере функция вернет пустую таблицу (или вообще nil или bid_count и offer_count = 0), хотя изменения были
Вы этого хотите? Умышленно пропускать цены?
Вам самим не страшно?
 
Не страшно.
ПОТАМУШТА.
С таймингами биржи/серверов/брокеров . . .
НАМ о "1201", КОТОРЫЙ в срез НЕ ПОПАЛ, . . . --  ВСЁ РАВНО.
пАчиму, . . . да потому, что нынешний алгоритм ARQA       НИЧЕГО лучшего НЕ ПРЕДЛОЖИЛ.
Мы как НЕ ЗНАЛИ о попадании в срез "1201" так и НЕ будем знать, НО (сократив ВРЕМЯ на обработку)
вместо 10 стаканов сможем себе позволить 100 (например, ИЛИ нагрузку на комп).
И лента нам (не всегда, но) -- в помощь.
 
УМЕНЬШИТЬ нагрузку на комп
 
Скажу (на всякий "пожарный").
Вы что хотите сказать?
Что существующий алгоритм позволяет ИЗБЕЖАТЬ ситуации, при которой возможно  "пропускать цены"???  . . .  )))
Что мы приобретем, я представляю.
Однако, я не очень представляю, что мы теряем.
Может, я чего-то не знаю (не понимаю) ???
 
PS. У меня такое ощущение, что Вы перепутали целесообразность с ответственностью.
Ранее она лежала исключительно на бирже, а сейчас Вы испугались, что она ляжет на Вас (ARQA).
Так вот, уверяю, что ВАША ответственность при реализации моей просьбы НИСКОЛЬКО не выше. ))
(Ваша нынешняя реализация НИЧЕГО не позволяет узнать о состоянии пропущенного среза стакана).
А правильно реализованный алгоритм той функции, о которой я прошу, ДАЖЕ в ответственности (в сравнении) -- гораздо лучший вариант,
чем предыдущие реализации getQuoteLevel2 с ошибками, о которых Вы, я уверен, -- осведомлены.
 
Цитата
PFelix написал:
да потому, что нынешний алгоритм ARQA
Не алгоритм ARQA, а алгоритм биржи. Почитайте биржевой протокол.
Никаких колбеков, только запрос=результат.
Как следствие срезы.

Цитата
PFelix написал:
УМЕНЬШИТЬ нагрузку на комп
Уверены?

Цитата
PFelix написал:
Однако, я не очень представляю, что мы теряем.
Стакан и так транслируется срезами, Вы хотите еще больше ухудшить ситуацию.

Цитата
PFelix написал:
PS. У меня такое ощущение, что Вы перепутали целесообразность с ответственностью.
Вы можете реализовать фильтрацию в своем алгоритме и далее уже оценить целесообразность.
После этого можно уже говорить о результате.

Цитата
PFelix написал:
о которых Вы, я уверен, -- осведомлены.
Поконкретнее пожалуйста.
 
Цитата
Sergey Gorokhov написал:
Поконкретнее пожалуйста.
https://forum.quik.ru/forum10/topic1502/
"Например" . . . , бывает, -- живем в реальном мире . . .
Цитата
Sergey Gorokhov написал:
Уверены?
100%. Компу не нужно будет "оборачивать" в LUA-таблицу весь стакан, а анализ/сравнение стакана с предыдущим его состоянием на нативной стороне на порядок быстрее.
Цитата
Sergey Gorokhov написал:
Стакан и так транслируется срезами, Вы хотите еще больше ухудшить ситуацию.
Объясните, плиз, чем информация об изменении среза информативнее информации о нем самом? Что мы/я в информации, полученной таким образом можем потерять/упустить. В приведенном Вами примере ИЗМЕНЕНИЯ строки с ценой 1201 (не попавшей в срез) НЕ БУДЕТ  НИ В НОВОМ СТАКАНЕ, ни в запрашиваемом мной изменении его состояния. Чем Ваш стакан информативнее его изменения.
и разумеется, . . . функция getQuoteLevel2 (getQuoteLevel2Ex) НУЖНА.
Цитата
Sergey Gorokhov написал:
Вы можете реализовать фильтрацию в своем алгоритме и далее уже оценить целесообразность.После этого можно уже говорить о результате.
Разумеется, могу, запросив результат через getQuoteLevel2, КОТОРАЯ БУДЕТ "В СЕБЕ" строить ПОЛНЫЙ СТАКАН, после чего мне (программе) надо будет его полностью принять ИЗ LUA на нативную сторону, . . . НА ЧТО И ТРАТИТСЯ  95-99 % времени = нагрузки на комп, СОЗДАННОЙ ИСКУССТВЕННО.
А я прошу Вас реализовать этот анализ на нативной стороне ("на всякий случай", НЕ СЕРВЕРА, а ТЕРМИНАЛА) ДО того, как строить одинаковую на 95% LUA-таблицу.
В результате, таблица сократится до 5%., а, значит, и нагрузка на комп, который СЕЙЧАС (при вызове getQuoteLevel2) обрабатывает не данные а ЛУА-стек.
 
Цитата
Sergey Gorokhov написал:
Не алгоритм ARQA, а алгоритм биржи. Почитайте биржевой протокол.
А где почитать, -- не подскажете?
 
Да, и вот еще нашел:
http://forex.kbpauk.ru/showflat.php/Cat/0/Number/344682/an/0/page/
Цитата:
Еще раз (just for double check), от сервера приходят только изменения, которые собираются в полный стакан самой библиотекой (или терминалом).
Есть еще источники. . .  
 
Цитата
PFelix написал:
Цитата
Sergey Gorokhov написал:
Не алгоритм ARQA, а алгоритм биржи. Почитайте биржевой протокол.
А где почитать, -- не подскажете?
на ФТП биржи ftp.moex.com

На остальные вопросы не вижу смысла отвечать.
Ознакомьтесь с протоколом, после чего многие вопросы сами отпадут.
 
Цитата
Sergey Gorokhov написал:
на ФТП биржи ftp.moex.com
"Там" много протоколов.
С частью из них знаком. А Вы -- про  какой?
 
Цитата
PFelix написал:
А Вы -- про  какой?

Ответ зависит от того про какой рынок идет речь.
Именно по вопросу про стаканы, разницы нет, что на срочном рынке, что на фондовом и валютном в поведении разницы нет.
 
Я, разумеется, могу чего-то не знать(, к чему уже "привык").  ))
Интересует FORTS.
И, как полагал, До последних двух лет там (от биржи до сервера QUIKвозможно, не непосредственно) использовался Plaza 2 (возможно, до сих пор).
А Plaza 2 - это полный анонимный ордерлог, где полный стакан (даже неагрегированный) можно получить единожды (и так его хранят архивы QScalp-a, который потом перестраивает (может перестраивать) стакан по результатам КАЖДОЙ следующей заявки).
Протокол позволяет на случай сбоев (уж не знаю в чем) передавать стакан полностью, чего QScalp НЕ ДЕЛАЕТ (не запрашивает и не получает, а зачем, и никаких сбоев, во всяком случае, в алгоритме не происходит).
Зачем стаканы получать серверу полностью, я не понимаю (так же, как и, признаюсь, с недоверием отношусь к таким заявлениям).
И вот это (лично для меня) мои "догадки" подтверждает.

Sergey Gorokhov написал:
https://forum.quik.ru/messages/forum10/message6732/topic685/#message6732
Добрый день, Мы провели разбор полученной информации и обнаружили причины описанной Вами проблемы. Временное "увеличение строк в стакане котировок" объясняется итеративностью в обновлении стакана котировок, когда обновляются ценовые уровни, один за другим. В связи с этим, при частом обновлении большого количества ценовых уровней, возникает возможность временно наблюдать окно котировок в состоянии, когда обновлена только часть ценовых уровней, а вторая часть ещё не обновлена и соответствует предыдущему состоянию. В этот момент в стакане могут появляться "лишние строки".
https://forum.quik.ru/messages/forum10/message6767/topic685/#message6767
Используется внутренний протокол QUIK который не подлежит разглашению.

НО . . .
дело , ведь НЕ В ПРОТОКОЛАХ.
Поймите, я не требую слать на терминал ЛЮБЫЕ изменения стакана, вызванные КАЖДОЙ меняющей его заявкой.
Цитата
PFelix написал:
Объясните, плиз, чем информация об изменении среза информативнее информации о нем самом? Что мы/я в информации, полученной таким образом можем потерять/упустить. В приведенном Вами примере ИЗМЕНЕНИЯ строки с ценой 1201 (не попавшей в срез) НЕ БУДЕТ  НИ В НОВОМ СТАКАНЕ, ни в запрашиваемом мной изменении его состояния. Чем Ваш стакан информативнее его изменения.и разумеется, . . . функция getQuoteLevel2 (getQuoteLevel2Ex) НУЖНА.
Опыт непонимания мной Ваших (ARQA) очевидных доводов имеется, а спустя месяца три ARQA признала мою правоту.
Жаль вот только результата ждал  месяцев 9.
К сожалению он оказался (так был реализован) непотребным, но спустя (в седьмой версии), вцелом  пользователи получили лучшее решение.
Цитата
PFelix написал:
Прошу зарегистрировать пожелание по развитию QUIK, а именноCделать в Qlua функцию, альтернативную getQuoteLevel2,Которая будет передавать массив ТОЛЬКО ИЗМЕНЕННЫХ строк в стакане.
 
Добрый день.
Нашел у себя p2gate_ru.pdf.
Посмотрел.
На стр. 71  Таблица orders_aggr: Агрегированные стаканы.
Понимаю.
Но, зачем. Читал еще где-то, что оная не шлется постоянно, а (например,) раз в 3 минуты (на всякий случай, либо по запросу).
Получается брокер гоняет трафик вместо данных. ЗАЧЕМ?
Ордерлог всё решает.
И заметьте, я не прошу "весь" стакан (все изменения), а лишь -- в пределах агрегированного (50 х 50 на FORTS).
 
Добрый день. Всех с прошедшими.
Не отвечает ARQA.
Посему "нечайно" перечитал топик.
В результате к автору по изначальной теме возникли замечания.
1. Чтобы правильно оценить время исследуемой операции, необходимо отнимать время, полученное между вызовами подряд процедуры определения времени. Хотя в данном случае это и не очень актуально.
2. Чтобы терминал не ставил данной задаче более низкий приоритет, желательно выполнять процедуру в калбеке.
 
Цитата
Sergey Gorokhov написал:
получив очередной срез стакана мы не можем никак узнать какие строки действительно изменились, а какие остались в прежнем состоянии.И проблема не в QLUA и не в самом QUIK, сама биржа так транслирует данные.
Сергей, а что мешает "запоминать" стакан и новый сравнивать с предыдущим?
 
Цитата
PFelix написал:
Посмотрел.
На стр. 71  Таблица orders_aggr: Агрегированные стаканы.
Понимаю.

Вот именно, что в QUIK транслируются агрегированные стаканы. Об этом и речь.
Такова реализация.

Цитата
PFelix написал:
Цитата
Sergey Gorokhov написал:
получив очередной срез стакана мы не можем никак узнать какие строки действительно изменились, а какие остались в прежнем состоянии.И проблема не в QLUA и не в самом QUIK, сама биржа так транслирует данные.
Сергей, а что мешает "запоминать" стакан и новый сравнивать с предыдущим?

то что при таком сравнении, будет ложное отсеивание.
На примере выше
Цитата
Sergey Gorokhov написал:
допустим были изменения в лучшем bid
1200 <- попал в срез
1201 <- НЕ попал в срез
1200 <- попал в срез

По Вашему предложению, сравниваем первый 1200 и последний 1200, т.к. они одинаковые то делаем вывод что изменений не было, в результате гипотетическая функция вернет nil, хотя по факту должна вернуть цифру.
В примере речь про цену, что наверное не совсем удачно, лучше представить что изменился объем, а не цена.
Как отличить эту ситуацию от той при которой изменений не было?
Никак.
Потому в описанном виде предложение звучит больше как вредное чем полезное.
 
Здравствуйте, .. . . .   Ой ответили . . . 5 дней я не ждал . . . "устал", . . . "прошу прощения".
Сейчас просматриваю, и . . . обнаружил, . . .
За ответ спасибо.
В Вашем примере таблица изменений должна прийти пустой, -- "всего-то делов".
Что имеем?
1. Мы "обременены знанием", что изменения были.
2. Как и Ваш "новый стакан", не отличающийся от "старого", пустая таблица -- ровно настолько же информативна (знаем, что изменения были, какие --  не понятно).

Собственно, вот о чём и прошу.
 
PS. Приходит Nil, и стакан (такой же ровно как "старый") принимать НЕ НАДО, прелесть -- в этом.
Страницы: 1 2 След.
Читают тему (гостей: 1)
Наверх