Сделал распечатку стаканов в моменты времени, когда 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 (за тот же интервал времени, при одинаковой глубине стакана).
стакан - это отображение очереди заявок. очередь заявок формирует сервер биржи. Он же производит исполнение сделок. Так вот, когда приходит заявка на покупку по цене выше лучшей цены продажи, то она в стакане должна встать выше лучшей цены продажи. Но она туда не ставится а производится совершение сделок и удаление из очереди заявок на продажу которые удовлетворяют данную заявку на покупку. Вот эти состояния очереди и не передает брокерам сервер биржи. т е такие не уравновешенные стаканы клиенты брокеров не видят. ----------------------------------- Как правило, сервер брокера транслирует клиентам не стакан а лишь изменения в стакане (про квик не знаю, но так делает транзак). Т е в терминале клиента тоже возникают момент удаления, перемещения и замещения записей. Если состояние изменяющегося На терминале стакана доступно клиенту, то будем видеть переменное число записей в стакане. Таким образом, те состояния стакана, которые видим в терминале - могут содержать переходные состояния с переменным числом элементов. Такой вид стакана - это не реальное состояние очереди, а техническое состояние таблицы на стороне терминала. Т е на сленге можно назвать это мусором. Показ такого мусора никто не регламентирует.
Не ITInvest реже, а Квик чаще, дергая OnQoute не по делу, когда стакан в процессе изменений. И пока что не видно способа надежно детектировать такие состояния стакана.
Старатель пишет: Michael Bulychev , тогда тем более не понятно, почему за основу потокобезопасных функций вы взяли table.insert/table.remove, а не свой вариант.
Николай Камынин пишет: Если надо работать с очередями с 5000 элементов, то надо просто написать спец модуль такой очереди для луа на СИ. ------------------------------------------------- Я делаю именно так для обработки больших массивов, очередей, списков, пулов, ну и т д --------------------------------- Полагаю, что если чел смело берется за потоки с очередями в 5000 элементов, то создать спец модуль очереди для него - раз плюнуть.
Мне кажется что различные очереди в скрипте как раз проще делать на Lua.
Николай Камынин пишет: Если надо работать с очередями с 5000 элементов, то надо просто написать спец модуль такой очереди для луа на СИ. ------------------------------------------------- Я делаю именно так для обработки больших массивов, очередей, списков, пулов, ну и т д --------------------------------- Полагаю, что если чел смело берется за потоки с очередями в 5000 элементов, то создать спец модуль очереди для него - раз плюнуть.
Мне кажется что различные очереди в скрипте как раз проще делать на Lua.
Если важно ПРОЩЕ, то, безусловно, Луа, но если важно БЫСТРО то , безусловно, СИ Но для очередей в 5000 элементов - важно быстро, так как иначе - нет смысла .
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. Картинка статичная, сделок нет.
Lua не работает с таблицами QUIK, а берет информацию напрямую с сервера брокера. Поэтому в этом месте рекомендуем обратиться к брокеру и если брокер затруднится в разборе проблемы, то инициируйте обращение к нам. Будем разбираться.
Lua не работает с таблицами QUIK, а берет информацию напрямую с сервера брокера. Поэтому в этом месте рекомендуем обратиться к брокеру и если брокер затруднится в разборе проблемы, то инициируйте обращение к нам. Будем разбираться.
Начинается обычный пинг-понг и пользователь в качестве мячика :( -- По вопросу написания и использования скриптов, прошу обращаться в техническую поддержку разработчика ПО Quik: http://arqatech.com/ru/support/
С уважением,
Владислав Сидельников Эксперт Департамент брокерского обслуживания Банк ВТБ (ПАО) --
Lua не работает с таблицами QUIK, а берет информацию напрямую с сервера брокера. Поэтому в этом месте рекомендуем обратиться к брокеру и если брокер затруднится в разборе проблемы, то инициируйте обращение к нам. Будем разбираться.
Начинается обычный пинг-понг и пользователь в качестве мячика :( -- По вопросу написания и использования скриптов, прошу обращаться в техническую поддержку разработчика ПО Quik: http://arqatech.com/ru/support/
С уважением,
Владислав Сидельников Эксперт Департамент брокерского обслуживания Банк ВТБ (ПАО) --