Тайминг функциональности QUIK из луа, как правильно замерить
Пользователь
Сообщений: Регистрация: 28.08.2018
08.10.2018 00:36:32
Попробовал гонять кое - какие тесты скорости своего скрипта. Один из тестов пытался отределить время затрачиваемое непосредственно на системный вызов 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, для имитации деятельности осуществлялся двукратный доступ ко всем содержательнм полям) возник у меня вопрос. Подскажите пожалуйста, порректно ли вообще измерять время на вызов функций квик подобным способом. Или "дерганье" их миллион раз подряд вызывает какие-то аномалии в работе квик?
QUIK clients support
Сообщений: Регистрация: 23.01.2015
08.10.2018 09:17:49
Цитата
BlackBoar написал: Подскажите пожалуйста, порректно ли вообще измерять время на вызов функций квик подобным способом. Или "дерганье" их миллион раз подряд вызывает какие-то аномалии в работе квик?
"дерганье" миллион раз не должно вызывать никаких аномалий. Другой вопрос в том что каждая итерация цикла может выполняться раз в 15.625 мс, почитать можно например тут:
Пользователь
Сообщений: Регистрация: 28.08.2018
08.10.2018 10:10:41
Цитата
Sergey Gorokhov написал: "дерганье" миллион раз не должно вызывать никаких аномалий.Другой вопрос в том что каждая итерация цикла может выполняться раз в 15.625 мс, почитать можно например тут:
Во-первых спасибо за консультации.
Далее, закрыл Visual Studio. ))) Убедился что таймер на умолчательных 15.6, повторил тесты. Результат лучше на ~17% Стакан 10х10 в диапазоне 65-73 микросекунды, стакан 20х20 125-135 микросекунд. Вопрос, похожи ли эти цифры на то что быть должно или следует искать еще узкие места?
Пользователь
Сообщений: Регистрация: 28.08.2018
08.10.2018 10:24:06
Апдейт, поэкспериментировал разворачивать цикл чтобы было меньше итераций самого цикла.
Лучший результат для стакана 10х10 где-то 55-65 микросекунд. Когда внутри цикла больше 100 строк кода похоже растут накладные расходы самого луа-движка, дальнейшее разворачивание уже ухудшает результат. Вопрос тот же, цифры уже похожи на то из чего можно исходить?
QUIK clients support
Сообщений: Регистрация: 23.01.2015
08.10.2018 10:58:52
Цитата
BlackBoar написал: Апдейт, поэкспериментировал разворачивать цикл чтобы было меньше итераций самого цикла. Лучший результат для стакана 10х10 где-то 55-65 микросекунд. Когда внутри цикла больше 100 строк кода похоже растут накладные расходы самого луа-движка, дальнейшее разворачивание уже ухудшает результат. Вопрос тот же, цифры уже похожи на то из чего можно исходить?
Боюсь что на этот вопрос нет ответа. Т.к. нет такого эталонного образца "то что должно быть"
Пользователь
Сообщений: Регистрация: 28.08.2018
08.10.2018 11:28:04
Цитата
Sergey Gorokhov написал: Боюсь что на этот вопрос нет ответа. Т.к. нет такого эталонного образца "то что должно быть"
Чисто любопытства ради попробую сформулировать вопрос по другому. В стакане NxN очевидно 4N содержательных цифр. Мой тестовый код имитирующий работу со стаканом получает каждую, умножает на какое-то число с плавающей точкой (сишный double), далее складывает с каким-то числом с плавающей точкой и потом сравнивает с еще каким-то числом с плавающей точкой. По результатам сравнения инкрементируется один из двух счетчиков. Так вот, вся эта активность занимает примерно в 400 раз меньше времени чем получение стакана. Такое соотношение выглядит нормально?
И еще вопрос по близкой теме. Глубину получения стаканов можно менять в настройках квик. А из скрипта луа есть аналогичная функциональность? И если нет можно ли выразить пожелание ее добавить?
Пользователь
Сообщений: Регистрация: 30.01.2015
08.10.2018 11:34:43
Конечно нормально. Исходим из того, что вы правильно поменяли время и сделали верные расчеты.
ваш запрос к терминалу на получение стакана ставится в терминале в очередь на обработку. И наверняка с низким приоритетом.
сначала выполняются важные для терминала действия, а потом уже дело доходит и до вашего скрипта.
Пасхалочка для Алексея Иванникова:
QUIK clients support
Сообщений: Регистрация: 23.01.2015
08.10.2018 11:36:45
Цитата
BlackBoar написал: И еще вопрос по близкой теме. Глубину получения стаканов можно менять в настройках квик. А из скрипта луа есть аналогичная функциональность? И если нет можно ли выразить пожелание ее добавить?
Из скрипта Lua вообще нет никакой штатной возможности менять какие-либо настройки терминала.
Пользователь
Сообщений: Регистрация: 28.08.2018
08.10.2018 11:43:33
Ситуация более-менее понятна, благодарю за ответы! Буду думать дальше )))
Пользователь
Сообщений: Регистрация: 28.08.2018
08.10.2018 11:50:04
Цитата
написал: ваш запрос к терминалу на получение стакана ставится в терминале в очередь на обработку. И наверняка с низким приоритетом.
Кстати. Я на самом деле не могу ничего возразить ибо понятия не имею что в недрах терминала происходит. Но вот тот факт что время отклика почти прямо пропорционально размеру стакана наводит на мысль что основные накладные расходы таки при его формировании. Мысль неконструктивная, способа послиять на формирование стакана не видно. Просто любопытно.
написал: ваш запрос к терминалу на получение стакана ставится в терминале в очередь на обработку. И наверняка с низким приоритетом.
Кстати. Я на самом деле не могу ничего возразить ибо понятия не имею что в недрах терминала происходит. Но вот тот факт что время отклика почти прямо пропорционально размеру стакана наводит на мысль что основные накладные расходы таки при его формировании. Мысль неконструктивная, способа послиять на формирование стакана не видно. Просто любопытно.
относительно стакана могу предположить следующее Так как данные стакана с биржи передаются в виде изменений стакана, то в терминале стакан хранится очевидно в виде списка. Вот из этого списка и формируется таблица луа. -------------------------- Ваши замеры близки к истине. Попробуйте еще измерить для сравнения время пустого цикла на луа ----------------------- Но эти замеры мало что дают для оценки быстродействия робота. Проблема в том что данные с сервера QUIK приходят блоками в которых собирается инфа за некоторое время. Возникает вопрос на сколько реально полученные данные запаздывают от их появления на бирже. Собственно успешность HFT робота и зависит от этого запаздывания. Попробуйте оценить это время и сравнить его со скоростью обработки полученных данных.
Пользователь
Сообщений: Регистрация: 28.08.2018
10.10.2018 00:02:20
Цитата
Николай Камынин написал: Попробуйте еще измерить для сравнения время пустого цикла на луа
В моих условиях ничего познавательного. Флуктуации вокруг нуля если можно так позволить себе выразиться. Придумал другой замер:
Код
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 робота и зависит от этого запаздывания.Попробуйте оценить это время и сравнить его со скоростью обработки полученных данных.
Дык понятно что крутым высокочастотником я при использовании квика не стану. Смысл замера в другом, если связываться работать со стаканами вообще - буду иметь представление о пропускной способности. И не создам сам себе узких мест. Постараюсь во всяком случае )))
Пользователь
Сообщений: Регистрация: 28.08.2018
14.10.2018 13:29:58
Возник еще вопрос по близкой в принципе теме, поэтому подниму эту. Допустим, есть СкриптА, торгует Si, и СкриптБ, торгует сбером. В каждом своя функция main исполняющаяся в своем потоке windows. В какой-то момент функция мэйн СкриптА вызывает getQuoteLevel2("SPBFUT", "SiZ8"). Стакан у брокера 50х50, соответственно вызов (для моего компа) будет исполняться 300+ микросекунд. Через микросекунду функция мэйн в СкриптБ выдает вызов getQuoteLevel2("TQBR", "SBER").
Что будет далее, СкриптБ будет стоять пока исполняется вызов из СкриптА или что-то еще?
Доп1: На getQuoteLevel2 свет клином естественно не сходился, взял ее же для примера потому что она одна из самых "долгих". Вопрос разумеется по ситуации с потоками вообще. Доп2: То что ситуация в примере говорит о неважном проектировании и вообще намекает на склонность к дерьмокодерству в курсе, опять же просто пример придумал на скорую руку )))
QUIK clients support
Сообщений: Регистрация: 23.01.2015
15.10.2018 15:30:28
Цитата
BlackBoar написал: Что будет далее, СкриптБ будет стоять пока исполняется вызов из СкриптА или что-то еще?
Не понял, я невнятно сформулировал вопрос или эта тема табу. Будет либо последовательное выполнение запросов либо параллельное (при наличии свободных процессорных ядер разумеется). "Ничего" быть не может раз уж скрипты вообще работают. Я разумеется могу рано или поздно протестировать сам, но был уверен что поддержка знает ответ. Странно както, при все уважении....
Не понял, я невнятно сформулировал вопрос или эта тема табу. Будет либо последовательное выполнение запросов либо параллельное (при наличии свободных процессорных ядер разумеется). "Ничего" быть не может раз уж скрипты вообще работают. Я разумеется могу рано или поздно протестировать сам, но был уверен что поддержка знает ответ. Странно както, при все уважении....
"Ничего не будет" означает что в описанном сценарии скрипты не будут друг другу мешать. Вы можете самостоятельно протестировать и убедиться в этом
Пользователь
Сообщений: Регистрация: 28.08.2018
15.10.2018 17:21:23
Цитата
Sergey Gorokhov написал: "Ничего не будет" означает что в описанном сценарии скрипты не будут друг другу мешать.Вы можете самостоятельно протестировать и убедиться в этом
Благодарю, именно это и хотел узнать не занимаясь разработкой очередного теста и размышлениями о его адекватности )))
Пользователь
Сообщений: Регистрация: 30.04.2015
28.12.2018 13:32:41
Добрый день. 1. Всех - "с наступающим". 2. Учитывая вышеписанное ("Итого, lua_pcall - порядка 99.1 - 99.3% всего времени" ... напомню, call была -- getQuoteLevel2), а также учитывая, что в подавляющем большинстве запросов стакан отличается от предыдущего не более, чем на 15%(а то и -- гораздо менее), а также учитывая, что нормальный API нам АRQA никогда не предоставит, Прошу зарегистрировать пожелание по развитию QUIK, а именно Cделать в Qlua функцию, альтернативную getQuoteLevel2, Которая будет передавать массив ТОЛЬКО ИЗМЕНЕННЫХ строк в стакане.
QUIK clients support
Сообщений: Регистрация: 23.01.2015
29.12.2018 09:41:47
Цитата
PFelix написал: Добрый день. 1. Всех - "с наступающим". 2. Учитывая вышеписанное ("Итого, lua_pcall - порядка 99.1 - 99.3% всего времени" ... напомню, call была -- getQuoteLevel2), а также учитывая, что в подавляющем большинстве запросов стакан отличается от предыдущего не более, чем на 15%(а то и -- гораздо менее), а также учитывая, что нормальный API нам АRQA никогда не предоставит, Прошу зарегистрировать пожелание по развитию QUIK, а именно Cделать в Qlua функцию, альтернативную getQuoteLevel2, Которая будет передавать массив ТОЛЬКО ИЗМЕНЕННЫХ строк в стакане.
Здравствуйте, К сожалению данное пожелание не может быть реализовано т.к. стаканы транслируются срезами. Т.е. получив очередной срез стакана мы не можем никак узнать какие строки действительно изменились, а какие остались в прежнем состоянии. И проблема не в QLUA и не в самом QUIK, сама биржа так транслирует данные.
Пользователь
Сообщений: Регистрация: 30.04.2015
29.12.2018 10:14:09
Добрый день. Сергей, я правильно Вас понял, что биржа (вероятно, всё-таки сервер QUIK) транслирует стакан каждый раз ПОЛНОСТЬЮ?
QUIK clients support
Сообщений: Регистрация: 23.01.2015
29.12.2018 10:35:46
Цитата
PFelix написал: Добрый день. Сергей, я правильно Вас понял, что биржа (вероятно, всё-таки сервер QUIK) транслирует стакан каждый раз ПОЛНОСТЬЮ?
Стаканы транслируются биржей каждый раз полностью.
Пользователь
Сообщений: Регистрация: 30.04.2015
29.12.2018 11:40:31
Понятно, спасибо. Однако, не понятно, почему нельзя сохранять предыдущий стакан (его состояние) и с ним сравнивать текущий. На нативной стороне это гораздо быстрее. После чего на сторону LUA отдавать только строки с измененным количеством лотов.
QUIK clients support
Сообщений: Регистрация: 23.01.2015
29.12.2018 12:07:37
Цитата
PFelix написал: Понятно, спасибо. Однако, не понятно, почему нельзя сохранять предыдущий стакан (его состояние) и с ним сравнивать текущий. На нативной стороне это гораздо быстрее. После чего на сторону LUA отдавать только строки с измененным количеством лотов.
Потому что нет никакой возможности определить что строка изменилась, в случае если визуально она не изменилась.
Банальный пример, цена между двумя срезами скакнула и вернулась в то же состояние что и на первом срезе. Изменение было? да было. Но визуально ничего не поменялось. И как это отличить от случая когда ничего не поменялось? Никак.
Пользователь
Сообщений: Регистрация: 30.04.2015
29.12.2018 12:34:59
Вот и славно. Калбек придет -- мы будем знать, что изменение было. А функция вернет пустую таблицу (или вообще nil или bid_count и offer_count = 0). Результат достигнут, -- время на построение LUA-таблиц при вызове альтернативной функции многократно сократится.
QUIK clients support
Сообщений: Регистрация: 23.01.2015
29.12.2018 13:25:51
Цитата
PFelix написал: Вот и славно. Калбек придет -- мы будем знать, что изменение было. А функция вернет пустую таблицу (или вообще nil или bid_count и offer_count = 0). Результат достигнут, -- время на построение LUA-таблиц при вызове альтернативной функции многократно сократится.
Кажется Вы не поняли о чем речь. Вы же сами сказали что надо отловить изменения. допустим были изменения в лучшем bid 1200 <- попал в срез 1201 <- НЕ попал в срез 1200 <- попал в срез
В Вашем примере функция вернет пустую таблицу (или вообще nil или bid_count и offer_count = 0), хотя изменения были Вы этого хотите? Умышленно пропускать цены? Вам самим не страшно?
Пользователь
Сообщений: Регистрация: 30.04.2015
29.12.2018 15:13:24
Не страшно. ПОТАМУШТА. С таймингами биржи/серверов/брокеров . . . НАМ о "1201", КОТОРЫЙ в срез НЕ ПОПАЛ, . . . -- ВСЁ РАВНО. пАчиму, . . . да потому, что нынешний алгоритм ARQA НИЧЕГО лучшего НЕ ПРЕДЛОЖИЛ. Мы как НЕ ЗНАЛИ о попадании в срез "1201" так и НЕ будем знать, НО (сократив ВРЕМЯ на обработку) вместо 10 стаканов сможем себе позволить 100 (например, ИЛИ нагрузку на комп). И лента нам (не всегда, но) -- в помощь.
Пользователь
Сообщений: Регистрация: 30.04.2015
29.12.2018 15:15:13
УМЕНЬШИТЬ нагрузку на комп
Пользователь
Сообщений: Регистрация: 30.04.2015
29.12.2018 15:21:15
Скажу (на всякий "пожарный"). Вы что хотите сказать? Что существующий алгоритм позволяет ИЗБЕЖАТЬ ситуации, при которой возможно "пропускать цены"??? . . . ))) Что мы приобретем, я представляю. Однако, я не очень представляю, что мы теряем. Может, я чего-то не знаю (не понимаю) ???
Пользователь
Сообщений: Регистрация: 30.04.2015
29.12.2018 16:21:56
PS. У меня такое ощущение, что Вы перепутали целесообразность с ответственностью. Ранее она лежала исключительно на бирже, а сейчас Вы испугались, что она ляжет на Вас (ARQA). Так вот, уверяю, что ВАША ответственность при реализации моей просьбы НИСКОЛЬКО не выше. )) (Ваша нынешняя реализация НИЧЕГО не позволяет узнать о состоянии пропущенного среза стакана). А правильно реализованный алгоритм той функции, о которой я прошу, ДАЖЕ в ответственности (в сравнении) -- гораздо лучший вариант, чем предыдущие реализации getQuoteLevel2 с ошибками, о которых Вы, я уверен, -- осведомлены.
QUIK clients support
Сообщений: Регистрация: 23.01.2015
29.12.2018 19:43:10
Цитата
PFelix написал: да потому, что нынешний алгоритм ARQA
Не алгоритм ARQA, а алгоритм биржи. Почитайте биржевой протокол. Никаких колбеков, только запрос=результат. Как следствие срезы.
100%. Компу не нужно будет "оборачивать" в LUA-таблицу весь стакан, а анализ/сравнение стакана с предыдущим его состоянием на нативной стороне на порядок быстрее.
Цитата
Sergey Gorokhov написал: Стакан и так транслируется срезами, Вы хотите еще больше ухудшить ситуацию.
Объясните, плиз, чем информация об изменении среза информативнее информации о нем самом? Что мы/я в информации, полученной таким образом можем потерять/упустить. В приведенном Вами примере ИЗМЕНЕНИЯ строки с ценой 1201 (не попавшей в срез) НЕ БУДЕТ НИ В НОВОМ СТАКАНЕ, ни в запрашиваемом мной изменении его состояния. Чем Ваш стакан информативнее его изменения. и разумеется, . . . функция getQuoteLevel2 (getQuoteLevel2Ex) НУЖНА.
Цитата
Sergey Gorokhov написал: Вы можете реализовать фильтрацию в своем алгоритме и далее уже оценить целесообразность.После этого можно уже говорить о результате.
Разумеется, могу, запросив результат через getQuoteLevel2, КОТОРАЯ БУДЕТ "В СЕБЕ" строить ПОЛНЫЙ СТАКАН, после чего мне (программе) надо будет его полностью принять ИЗ LUA на нативную сторону, . . . НА ЧТО И ТРАТИТСЯ 95-99 % времени = нагрузки на комп, СОЗДАННОЙ ИСКУССТВЕННО. А я прошу Вас реализовать этот анализ на нативной стороне ("на всякий случай", НЕ СЕРВЕРА, а ТЕРМИНАЛА) ДО того, как строить одинаковую на 95% LUA-таблицу. В результате, таблица сократится до 5%., а, значит, и нагрузка на комп, который СЕЙЧАС (при вызове getQuoteLevel2) обрабатывает не данные а ЛУА-стек.
Пользователь
Сообщений: Регистрация: 30.04.2015
04.01.2019 13:36:51
Цитата
Sergey Gorokhov написал: Не алгоритм ARQA, а алгоритм биржи. Почитайте биржевой протокол.
А где почитать, -- не подскажете?
Пользователь
Сообщений: Регистрация: 30.04.2015
04.01.2019 14:09:18
Да, и вот еще нашел:
Цитата: Еще раз (just for double check), от сервера приходят только изменения, которые собираются в полный стакан самой библиотекой (или терминалом). Есть еще источники. . .
Ответ зависит от того про какой рынок идет речь. Именно по вопросу про стаканы, разницы нет, что на срочном рынке, что на фондовом и валютном в поведении разницы нет.
Пользователь
Сообщений: Регистрация: 30.04.2015
05.01.2019 14:08:18
Я, разумеется, могу чего-то не знать(, к чему уже "привык"). )) Интересует FORTS. И, как полагал, До последних двух лет там (от биржи до сервера QUIKвозможно, не непосредственно) использовался Plaza 2 (возможно, до сих пор). А Plaza 2 - это полный анонимный ордерлог, где полный стакан (даже неагрегированный) можно получить единожды (и так его хранят архивы QScalp-a, который потом перестраивает (может перестраивать) стакан по результатам КАЖДОЙ следующей заявки). Протокол позволяет на случай сбоев (уж не знаю в чем) передавать стакан полностью, чего QScalp НЕ ДЕЛАЕТ (не запрашивает и не получает, а зачем, и никаких сбоев, во всяком случае, в алгоритме не происходит). Зачем стаканы получать серверу полностью, я не понимаю (так же, как и, признаюсь, с недоверием отношусь к таким заявлениям). И вот это (лично для меня) мои "догадки" подтверждает.
Sergey Gorokhov написал:
Добрый день, Мы провели разбор полученной информации и обнаружили причины описанной Вами проблемы. Временное "увеличение строк в стакане котировок" объясняется итеративностью в обновлении стакана котировок, когда обновляются ценовые уровни, один за другим. В связи с этим, при частом обновлении большого количества ценовых уровней, возникает возможность временно наблюдать окно котировок в состоянии, когда обновлена только часть ценовых уровней, а вторая часть ещё не обновлена и соответствует предыдущему состоянию. В этот момент в стакане могут появляться "лишние строки".
Используется внутренний протокол QUIK который не подлежит разглашению.
НО . . . дело , ведь НЕ В ПРОТОКОЛАХ. Поймите, я не требую слать на терминал ЛЮБЫЕ изменения стакана, вызванные КАЖДОЙ меняющей его заявкой.
Цитата
PFelix написал: Объясните, плиз, чем информация об изменении среза информативнее информации о нем самом? Что мы/я в информации, полученной таким образом можем потерять/упустить. В приведенном Вами примере ИЗМЕНЕНИЯ строки с ценой 1201 (не попавшей в срез) НЕ БУДЕТ НИ В НОВОМ СТАКАНЕ, ни в запрашиваемом мной изменении его состояния. Чем Ваш стакан информативнее его изменения.и разумеется, . . . функция getQuoteLevel2 (getQuoteLevel2Ex) НУЖНА.
Опыт непонимания мной Ваших (ARQA) очевидных доводов имеется, а спустя месяца три ARQA признала мою правоту. Жаль вот только результата ждал месяцев 9. К сожалению он оказался (так был реализован) непотребным, но спустя (в седьмой версии), вцелом пользователи получили лучшее решение.
Цитата
PFelix написал: Прошу зарегистрировать пожелание по развитию QUIK, а именноCделать в Qlua функцию, альтернативную getQuoteLevel2,Которая будет передавать массив ТОЛЬКО ИЗМЕНЕННЫХ строк в стакане.
Пользователь
Сообщений: Регистрация: 30.04.2015
07.01.2019 10:47:41
Добрый день. Нашел у себя p2gate_ru.pdf. Посмотрел. На стр. 71 Таблица orders_aggr: Агрегированные стаканы. Понимаю. Но, зачем. Читал еще где-то, что оная не шлется постоянно, а (например,) раз в 3 минуты (на всякий случай, либо по запросу). Получается брокер гоняет трафик вместо данных. ЗАЧЕМ? Ордерлог всё решает. И заметьте, я не прошу "весь" стакан (все изменения), а лишь -- в пределах агрегированного (50 х 50 на FORTS).
Пользователь
Сообщений: Регистрация: 30.04.2015
09.01.2019 11:52:13
Добрый день. Всех с прошедшими. Не отвечает ARQA. Посему "нечайно" перечитал топик. В результате к автору по изначальной теме возникли замечания. 1. Чтобы правильно оценить время исследуемой операции, необходимо отнимать время, полученное между вызовами подряд процедуры определения времени. Хотя в данном случае это и не очень актуально. 2. Чтобы терминал не ставил данной задаче более низкий приоритет, желательно выполнять процедуру в калбеке.
Пользователь
Сообщений: Регистрация: 30.04.2015
09.01.2019 12:00:48
Цитата
Sergey Gorokhov написал: получив очередной срез стакана мы не можем никак узнать какие строки действительно изменились, а какие остались в прежнем состоянии.И проблема не в QLUA и не в самом QUIK, сама биржа так транслирует данные.
Сергей, а что мешает "запоминать" стакан и новый сравнивать с предыдущим?
написал: получив очередной срез стакана мы не можем никак узнать какие строки действительно изменились, а какие остались в прежнем состоянии.И проблема не в QLUA и не в самом QUIK, сама биржа так транслирует данные.
Сергей, а что мешает "запоминать" стакан и новый сравнивать с предыдущим?
то что при таком сравнении, будет ложное отсеивание. На примере выше
Цитата
Sergey Gorokhov написал: допустим были изменения в лучшем bid 1200 <- попал в срез 1201 <- НЕ попал в срез 1200 <- попал в срез
По Вашему предложению, сравниваем первый 1200 и последний 1200, т.к. они одинаковые то делаем вывод что изменений не было, в результате гипотетическая функция вернет nil, хотя по факту должна вернуть цифру. В примере речь про цену, что наверное не совсем удачно, лучше представить что изменился объем, а не цена. Как отличить эту ситуацию от той при которой изменений не было? Никак. Потому в описанном виде предложение звучит больше как вредное чем полезное.
Пользователь
Сообщений: Регистрация: 30.04.2015
18.02.2019 13:49:05
Здравствуйте, .. . . . Ой ответили . . . 5 дней я не ждал . . . "устал", . . . "прошу прощения". Сейчас просматриваю, и . . . обнаружил, . . . За ответ спасибо. В Вашем примере таблица изменений должна прийти пустой, -- "всего-то делов". Что имеем? 1. Мы "обременены знанием", что изменения были. 2. Как и Ваш "новый стакан", не отличающийся от "старого", пустая таблица -- ровно настолько же информативна (знаем, что изменения были, какие -- не понятно).
Собственно, вот о чём и прошу.
Пользователь
Сообщений: Регистрация: 30.04.2015
18.02.2019 13:51:33
PS. Приходит Nil, и стакан (такой же ровно как "старый") принимать НЕ НАДО, прелесть -- в этом.
Пользователь
Сообщений: Регистрация: 30.04.2015
18.02.2019 14:02:59
PPS. Вместо пустой таблицы QLUA может отправить Nil (например).
Пользователь
Сообщений: Регистрация: 30.04.2015
21.03.2019 14:38:30
Цитата
Sergey Gorokhov написал: В примере речь про цену, что наверное не совсем удачно, лучше представить что изменился объем, а не цена.Как отличить эту ситуацию от той при которой изменений не было?Никак. Потому в описанном виде предложение звучит больше как вредное чем полезное.
Думал, может, за определенное время дойдет до саппорта/разработчиков, или, может, роботостроители поддержат. . . Сергей "ситуации" отличаются именно ТЕМ, что приходит калбек (хотя измененный стакан в срез не попал). Если изменений не было, -- и калбека не было. А полезность заключается именно в том, что на стороне клиента не нужно принимать стакан, т.к. он от предыдущего отличаться НЕ БУДЕТ. Но, если пришел калбек, скрипт "знает", что изменения в стакане были, но время тратить на получение стакана бессмысленно.
При частичном изменении мы могли бы получать только строки с изменившимся объемом (т.е., например всего 3 строки вместо 100).
Господа роботостроители, прошу поддержать или объяснить, в чем я заблуждаюсь.
