Ошибки в функции getQuoteLevel2!!!

Страницы: Пред. 1 2
RSS
Ошибки в функции getQuoteLevel2!!!, Возвращаемый стакан котировок не всегда соответствует (нормальным) условиям...
 
Сделал распечатку стаканов в моменты времени, когда bid_count>50 || offer_count>50.
http://pastebin.com/WfF4FkDg
что там:
-штамп времени
-три стакана в ряд (до проблемного момента, сам момент и следующий за ним)
для каждого стакана в скобках указано bid_count и offer_count, bids - слева от цены, asks - справа. Инструмент - RIZ2, цена -  в шагах.
Что интересного подметил. На примере последней тройки стаканов. Появляется "лишний" 51-ый bid на цене 13866 (средний стакан). Зачем? Ответ - в следующем стакане(справа) исчезает bid на цене 13916, снова все нормально.
Вывод: на момент времени среднего стакана уже было известно, что bid по 13916 исчез, но узнаем мы об этом с задержкой, ничем не обоснованной. Ту информацию, что ближе к спреду надо бы обновлять более приоритетно.
 
Цитата
user пишет:
Ту информацию, что ближе к спреду надо бы обновлять более приоритетно.
При чём тут приоритетное обновление?!
Есть правила торгов, согласно которым исполняются ордера. Согласно этим правилам, ордера всегда исполняются последовательно (пусть даже по несколько штук в единицу времени) в порядке очереди.
Исполнение ордеров приводит к изменению стакана таким же образом в строгой последовательности.
Если соблюдать эту последовательность изменений при отображении "стакана", то никогда даже при частичном обновлении "ценовых уровней" не возникнет пересечения котировок. Отсюда вытекает вывод, что в QUIK эта последовательность изменений строк в "стаканах" нарушается.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Цитата
user пишет:
Ту информацию, что ближе к спреду надо бы обновлять более приоритетно.
При чём тут приоритетное обновление?!
Есть правила торгов, согласно которым исполняются ордера. Согласно этим правилам, ордера всегда исполняются последовательно (пусть даже по несколько штук в единицу времени) в порядке очереди.
Исполнение ордеров приводит к изменению стакана таким же образом в строгой последовательности.
Если соблюдать эту последовательность изменений при отображении "стакана", то никогда даже при частичном обновлении "ценовых уровней" не возникнет пересечения котировок. Отсюда вытекает вывод, что в QUIK эта последовательность изменений строк в "стаканах" нарушается.
Предположу, что не совсем так.
Просто сервер биржи не транслирует стакана, пока не урегулирует очередь.
Но обновление очереди на сервере QUIK или в терминале может проходить без запрета и мы видим промежуточное состояние стакана.
Но это состояние уже прошло, как и много других до того как мы это увидели.
Кроме того, право разработчика сделать так как он считает нужным, поскольку нигде не регламентируется работа КВИК с очередями.
 
Цитата
Николай Камынин пишет:
Просто сервер биржи не транслирует стакана, пока не урегулирует очередь.
Но обновление очереди на сервере QUIK или в терминале может проходить без запрета и мы видим промежуточное состояние стакана.
"Без запрета" чего? Что такое "промежуточное состояние стакана". Откуда оно появилось, если первоисточником для QUIK является биржа?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Николай Камынин пишет:
Предположу, что не совсем так.
Просто сервер биржи не транслирует стакана, пока не урегулирует очередь.
Предположу, что сервер биржи вообще ничего не знает о стакане. Стакана ещё нет!!! Биржа передаёт поток транзакций(новые заявки, отменённые заявки, переставленные заявки, частично исполненные) не более. А этот поток уже принимает серверная часть брокера, там то и рождается стакан!!!  Причём, мой брокер на одном сервере создаёт стакан с глубиной 10, а на другом сервере с глубиной 20, из одного и того же потока два разных стакана.
 
Добрый день!

Сервер Quik получает стаканы с биржи и отображает их в терминале  ровно в том виде, в котором они транслируются, без "очередей" и "рождения стакана на серверной стороне брокера". В разных клиентских терминалах, например Quik и прямой терминал биржи - стаканы должны и будут совпадать.
 
Цитата
Alexandr Shumilin пишет:
Сервер Quik получает стаканы с биржи и отображает их в терминалеровно в том виде, в котором они транслируются, без "очередей" и "рождения стакана на серверной стороне брокера". В разных клиентских терминалах, например Quik и прямой терминал биржи - стаканы должны и будут совпадать.
Спасибо. Прояснили :)
 
Цитата
Alexandr Shumilin пишет:
Сервер Quik получает стаканы с биржи и отображает их в терминале ровно в том виде, в котором они транслируются.
В разных клиентских терминалах, например Quik и прямой терминал биржи - стаканы должны и будут совпадать.
А почему тогда у разных брокеров или на разных серверах одного брокера стаканы разной глубины?
Сервер Quik просто удаляет "лишние" строки (полученные с биржи) перед отправкой на терминал клиента? Или они приходят с биржи разной глубины?
 
Цитата
Alexandr Shumilin пишет:
В разных клиентских терминалах, например Quik и прямой терминал биржи - стаканы должны и будут совпадать.
У меня есть записи стаканов от itinvest. Там не наблюдается такого, чтобы bid_count или offer_count стали в какой-то момент больше номинала ( по 50, в каждую сторону). Еще, замечено, что количество событий OnQuote в Квике всегда заметно больше, чем в itinvest (за тот же интервал времени, при одинаковой глубине стакана).
 
стакан - это отображение очереди заявок.
очередь заявок формирует сервер биржи.
Он же производит исполнение сделок.
Так вот, когда приходит заявка на покупку по цене выше лучшей цены продажи,
то она в стакане должна встать выше лучшей цены продажи.
Но она туда не ставится а производится совершение сделок и удаление из очереди заявок на продажу которые удовлетворяют данную заявку на покупку.
Вот эти состояния очереди и не передает брокерам сервер биржи. т е такие не уравновешенные стаканы клиенты брокеров не видят.
-----------------------------------
Как правило, сервер брокера транслирует клиентам не стакан а лишь изменения в стакане (про квик не знаю, но так делает транзак).
Т е в терминале клиента тоже возникают момент удаления, перемещения и замещения записей.
Если состояние изменяющегося На терминале стакана доступно клиенту, то будем видеть переменное число записей в стакане.
Таким образом, те состояния стакана, которые видим в терминале - могут содержать переходные состояния с переменным числом элементов.
Такой вид стакана - это не реальное состояние очереди, а техническое состояние таблицы на стороне терминала.
Т е на сленге можно назвать это мусором.
Показ такого мусора никто не регламентирует.
 
Цитата
user пишет:
количество событий OnQuote в Квике всегда заметно больше, чем в itinvest (за тот же интервал времени, при одинаковой глубине стакана)
Думаю, это говорит отнюдь не в пользу ITInvest. Скорей всего, это значит, что они передают изменения стакана реже, чем это делает Quik.
 
Не  ITInvest реже, а Квик чаще, дергая OnQoute не по делу, когда стакан в процессе изменений.
И пока что не видно способа надежно детектировать такие состояния стакана.
 
Реже-чаще... Предлагаю сделать запись изменений стакана в QUIK и ITInvest в одно и то же время и сравнить.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Michael Bulychev , тогда тем более не понятно, почему за основу потокобезопасных функций вы взяли table.insert/table.remove, а не свой вариант.
Потому что именно их и просили.
 
Цитата
Николай Камынин пишет:
Если надо работать с очередями с 5000 элементов,
то надо просто написать спец модуль такой очереди для луа на СИ.
-------------------------------------------------
Я делаю именно так для обработки больших массивов, очередей, списков, пулов, ну и т д
---------------------------------
Полагаю, что если чел смело берется за потоки с очередями в 5000 элементов,
то создать спец модуль очереди для него - раз плюнуть.
Мне кажется что различные очереди в скрипте как раз проще делать на Lua.
 
Цитата
Michael Bulychev пишет:
Цитата
Николай Камынин пишет:
Если надо работать с очередями с 5000 элементов,
то надо просто написать спец модуль такой очереди для луа на СИ.
-------------------------------------------------
Я делаю именно так для обработки больших массивов, очередей, списков, пулов, ну и т д
---------------------------------
Полагаю, что если чел смело берется за потоки с очередями в 5000 элементов,
то создать спец модуль очереди для него - раз плюнуть.
Мне кажется что различные очереди в скрипте как раз проще делать на Lua.
Если важно ПРОЩЕ, то, безусловно, Луа,
но если важно БЫСТРО то , безусловно, СИ
Но для очередей в 5000 элементов - важно быстро, так как иначе - нет смысла .
 
Цитата
Sergey Gorokhov пишет:
Цитата
DronGO пишет:
Цитата
Sergey Gorokhov пишет:
Здравствуйте,
Просьба привести пример скрипта считывающего bid_count и offer_count
Также сообщите версию терминала и уточните это боевой доступ или тестовый?
Добрый день Сергей. Версия терминала 6.17.1.17Сервер реальных торгов. Скрипт небольшой написал, в нем нужно только два параметра установить, в соответствии с Вашей глубиной стакана.Скрипт выводит информацию на консоль программы DebugView для визуального контроля. А так же сохраняет в файл log_errors_in_quotes.txt
Здравствуйте!

Информация получена, проблема изучается. Постараемся в ближайшее время дать ответ.
Добрый день.

Обнаруженная Вами ошибка исправлена в серверном ПО QUIK версии 5.0.
 
Добрый день !

Вчера (пятница 29/06/18) произошел странный сбой, который обошелся мне в приличную сумму.
С утра перестал отвечать основной сервер брокера ВТБ и все переключились на Сервер2.
Ближе к обеду я обратил внимание на некорректное выставление заявок скриптом QUIK.
После разбирательства выяснилось, что функция getQuoteLevel2() возвращает данные, которые не соответствуют содержимому стакана.

Конкретный трейс - в открытом стакане Алросы нижний оффер 98.64, верхний бид 98.62. Картинка статичная, сделок нет.

Запрос
...
local gql=getQuoteLevel2(x_classcode,x_seccode)
return gql.bid[1].price
...
возвращает значения:  98.64, 98.68, 98.42...

В общем вместо первого бида в таблице возвращалось что-попало.

В связи с этим хотел узнать , берет ли функция данные из открытого в квике стакана или это дерьмо лезет напрямую с сервера брокера ?

 Если будут предложения, как в такую ситуацию больше не попадать, заранее спасибо!
 
Добрый день.


Lua не работает с таблицами QUIK, а берет информацию напрямую с сервера брокера.
Поэтому в этом месте рекомендуем обратиться к брокеру и если брокер затруднится в разборе проблемы,
то инициируйте обращение к нам. Будем разбираться.
 
Цитата
Egor Zaytsev написал:
Добрый день.


Lua не работает с таблицами QUIK, а берет информацию напрямую с сервера брокера.
Поэтому в этом месте рекомендуем обратиться к брокеру и если брокер затруднится в разборе проблемы,
то инициируйте обращение к нам. Будем разбираться.
Начинается обычный пинг-понг и пользователь в качестве мячика :(
--
По вопросу написания и использования скриптов, прошу обращаться в техническую поддержку разработчика ПО Quik: http://arqatech.com/ru/support/

С уважением,

Владислав Сидельников
Эксперт
Департамент брокерского обслуживания
Банк ВТБ (ПАО)
--
 
Цитата
Kolossi написал:
Цитата
Egor Zaytsev   написал:
Добрый день.


Lua не работает с таблицами QUIK, а берет информацию напрямую с сервера брокера.
Поэтому в этом месте рекомендуем обратиться к брокеру и если брокер затруднится в разборе проблемы,
то инициируйте обращение к нам. Будем разбираться.
Начинается обычный пинг-понг и пользователь в качестве мячика :(
--
По вопросу написания и использования скриптов, прошу обращаться в техническую поддержку разработчика ПО Quik:  http://arqatech.com/ru/support/

С уважением,

Владислав Сидельников
Эксперт
Департамент брокерского обслуживания
Банк ВТБ (ПАО)
--
Ответили Вам почтой.
Страницы: Пред. 1 2
Читают тему
Наверх