Время изменения стакана получаемого через OnQuotes

Страницы: 1
RSS
Время изменения стакана получаемого через OnQuotes, OnQuotes - есть ли возможность параллельно с чтением стакана, получить точное время торгового сервера, когда он возник/изменился
 
С помощью OnQuotes записываю "слепки" стаканов в файл. Несложно узнать серверное время получения стакана пользователем (мной), например, с помощью функции getInfoParam('SERVERTIME').
Однако, очевидно, что время получения стакана и его генерации на сервере биржи будут отличаться -- требуется а) время чтобы доставить стакан, а также б) время на работу алгоритма. При этом компонента а) может от случая к случаю сильно разниться, соответственно, будет все время меняться и период запаздывания связанный с доставкой данных по стакану. В этой связи интересно знать, есть ли какой-либо маркер на сервере биржи отмечающий время генерации/изменения стакана и возможность его получить средствами quik | lua
 
стакан возникает в момент его создания на экране
потом сервер присылает изменения которые добавляются в стакан.
время обновления можно узнать при вызове колбека  OnQuote функцией
getInfoParam ("SERVERTIME")
-------------------------------
Замечу следующее. Если есть желание знать время биржи, которое может отличаться от времени сервера, то синхронизируйте часы своего компа по серверу точного времени и читайте локальное время. Погрешность составить 10-100 ms.
 
О синхронизации локального времени с сервером точного времени.
 
Раз в час синхронизирую время с сервером точного времени ntp1.vniiftri.ru. Сразу после этого  локальное время и время биржи если и отличаются, то не слишком заметно.
Но за час расхождение достигает нескольких секунд.  
 
Вы не получите точное время.
1. Биржа его не говорит
2. Квик может отправлять не все изменения биржевого стакана для инструментом со слишком активными торгами
 
Цитата
swerg написал:
Вы не получите точное время.
1. Биржа его не говорит
2. Квик может отправлять не все изменения биржевого стакана для инструментом со слишком активными торгами
Вы меня правильно поняли. У меня было подозрение, что все именно так. Есть опыт / идеи борьбы с проблемой?
Цитата
Борис Гудылин написал:
OnQuote
Время синхронизировано на компе и сервере. Это не проблема.
Цитата
Николай Камынин написал:
OnQuote
Я уже говорил. Поскольку сСтакан формируется на бирже, а OnQoute - на терминале пользователя. SERVERTIME указывает время последней генерации, которая происходит позже. Это проблема. Для сделок. например, можно узнать точное время именно биржи, а для стакана, как я подозреваю - нет. Это "нихт гду."
 
Цитата
Борис Гудылин написал:
О синхронизации локального времени с сервером точного времени.
 
Раз в час синхронизирую время с сервером точного времени ntp1.vniiftri.ru. Сразу после этого  локальное время и время биржи если и отличаются, то не слишком заметно.
Но за час расхождение достигает нескольких секунд.
Во-первых, биржа тоже синхронизируется по серверу точного времени. и гораздо точнее чем ваш комп.
Во-вторых, синхронизируйте на раз в час а как хотите быстрее. Я синхронизирую раз в пять минут.
В-третьих, в винде есть алгоритм автоподстройки времени, который обеспечивает погрешность указанную ранее.
Вот результаты моих исследований этого вопроса (по оси Y - погрешность в секундах):
 
Спасибо.  
 
Здравствуйте, "тема уже поднималась", но безрезультатно, или почти так.
Зачем время изменения стакана, чтоб "по максимуму" синхронизировать его с лентой?
Если только для этого, то не проще ли (а, возможно, и - точнее, а может быть даже, это ключ к механизму синхронизации.
Уважаемые разработчики, ответьте, пжлст, на такой вопрос.
Если "мы подписались на ленту" "через CDS", и следим за порядком следования калбеков,
можно ли утверждать, что все сделки в ленте на бирже сработали раньше, чем момент временного среза стакана, ЕСЛИ
калбеки OnAllTrade пришли раньше очередного OnQuotes, и наоборот
сделки прошли позже, если соответствующие калбеки OnAllTrade пришли позже очередного OnQuotes.
Иными словами порядок следования событий свершения сделок и фиксации состояния стакана не нарушается и совпадает
с порядком следования соответствующих калбеков?
Спасибо.
 
Такой сложный вопросили раскрыл САКРАЛЬНОЕ ЗНАНИЕ?
 
Цитата
PFelix написал:
Такой сложный вопросили раскрыл САКРАЛЬНОЕ ЗНАНИЕ?
Ответ на свой вопрос Вы найдете изучив следующее:
1) Особенности обмена информацией при использовании Интернет
2) Особенности протокола TCP. Понятие пакетной передачи, маршрутизации.
3) Алгоритм Нейгла(Нагла)
Успехов
 
Николай, не напускайте туману.
1. В скрипт калбеки по ленте приходят в нужном порядке.
2. Вопрос был адресован
Цитата
PFelix написал:
Уважаемые разработчики
3 Я не вчера родился, а Вы про меня мало, что знаете.
4. Для начала бы понять, един ли источник информации, т.е. сервер ли ПРОСТО "перетранслирует" биржевые пакеты или тот стакан, который приходит в терминал, "рождается" по определенному алгоритму не сервере брокера.
 
. . .  НА сервере брокера?
 
Рождается на сервере брокера. Выше был намек.
ну и потом, это ведь очевидно, что сервер и терминал общаются по протоколу, отличному от биржевого.
хотя бы потому, что бирж много, а терминал - один.
 
"Лента" - это "Все сделки"?
 
Цитата
PFelix написал:
Иными словами порядок следования событий свершения сделок и фиксации состояния стакана не нарушается и совпадает
с порядком следования соответствующих калбеков?
стаканы едут срезами, также как и таблица торгов, только срезы обновляются чаще.
а таблица обезличенных сделок, едет сплошным потоком.
так что изменение обезличенных сделок легко может попасть между срезами стакана.
И потом, никакой синхронизации биржевых потоков со стороны QUIK нет, и не будет.
 
Цитата
Николай Камынин написал:
Цитата
Борис Гудылин   написал:
О синхронизации локального времени с сервером точного времени.
 
Раз в час синхронизирую время с сервером точного времени ntp1.vniiftri.ru. Сразу после этого  локальное время и время биржи если и отличаются, то не слишком заметно.
Но за час расхождение достигает нескольких секунд.
Во-первых, биржа тоже синхронизируется по серверу точного времени. и гораздо точнее чем ваш комп.
Во-вторых, синхронизируйте на раз в час а как хотите быстрее. Я синхронизирую раз в пять минут.
В-третьих, в винде есть алгоритм автоподстройки времени, который обеспечивает погрешность указанную ранее.
Вот результаты моих исследований этого вопроса (по оси Y - погрешность в секундах):
Николай, я уже объяснил, ваше пояснение не имеет отношения к теме моего вопроса и поднятой проблемы, хотя и интересно само по себе. Я получаю и использую время сервера, а не моего ПК. Оно может быть сколь угодно рассинхронизовано, это никак не влияет на результат.  
 
Иван Ру,
Возможно я не понял Вашу задачу, но хочу обратить внимание на неточность в Ваших рассуждениях.
------------------------------------------
Во-первых, тот факт что пакеты в TCP соединении  приходят последовательно  не может знать пользователь винды.
Речь идет о пакетах протокола TCP и они собираются стеком TCP, что пользователем не доступно.
---------------------------------------------
Во-вторых, интернет построен на маршрутизаторах - а это и есть разное время движение пакетов и возможность их прихода как раньше так и позже.
--------------------------------------------------------
В-третьих, время сервера брокера - это время когда в терминал пришла последняя партия данных с сервера. Это может быть и не стакан.
----------------------------------------------------
В-четвертых, поток сделок тоже идет блоками. В одном блоке, который придет в одно время сервера будут сделки с различным временем биржи.
-----------------------------------------------------
В итоге,
сделкам совершенным в разное время будет соответствовать одно и тоже время сервера брокера, а это значит,
сделки могут опередить заявки в стакане, по которым они совершены.
---------------------------------------
Поэтому в терминале QUIK и на обычных каналах интернет возможна синхронизация сделок и заявок лишь очень примерно.
----------------------
На это я и пытался обратить Ваше внимание.
 
Цитата
Николай Камынин написал:
В-третьих, время сервера брокера - это время когда в терминал пришла последняя партия данных с сервера. Это может быть и не стакан.
----------------------------------------------------
В-четвертых, поток сделок тоже идет блоками. В одном блоке, который придет в одно время сервера будут сделки с различным временем биржи.
Нелогичности в своих рассуждения не вижу, судя по пунктам 3-4 Вы теперь уловили суть вопроса, Ваши разъяснения подтверждают, а не опровергают наличие обозначенной мной проблемы. Для сделок, в коллбэке alltrade есть параметр datetime указывающий на момент их совершения (насколько я понимаю) . Для onQoutes аналогичного параметра я не вижу, что создает проблемы.  
 
Цитата
Sergey Gorokhov написал:
изменение обезличенных сделок легко может попасть между срезами стакана
1. изменение таблицы, т.е. приход "новых" сделок (или Вы о другом)
2. а разве сделки могут проходить как-то иначе (не между временными срезами).
Ну, и и к вопросу,
если биржа транслирует сделки и изменения в  стакане последовательно, а сервер брокера их также последовательно ретранслирует, то нарушений в последовательности быть не должно.
Разумеется, стакан претерпевает от среза до среза несколько изменений.
Важно, что все протранслированные сделки были ДО текущего состояния стакана, а те которые будут протранслированы позже, значит -- позже того же состояния стакана.
Также прошу заметить:
1. я на этом не настаиваю, просто хочется понять как работают ваши алгоритмы.
2. разумеется, если я не прав (не так они работают, как я описАл), никто за несинхронизацию претензий к вам предъявлять не собирается.
 
Цитата
PFelix написал:
сделки прошли позже, если соответствующие калбеки OnAllTrade пришли позже очередного OnQuotes
Всё просто: подключитесь в середине торговой сессии к терминалу и понаблюдайте за ТОС (при выключенной галке "Получать информацию по обезличенным сделкам с текущего момента") и стаканом. Думаю, вы сами всё поймёте.
 
Цитата
PFelix написал:
1. изменение таблицы, т.е. приход "новых" сделок (или Вы о другом)
Для таблицы обезличенных сделок, "приход" сделки и изменение таблицы, это одно и тоже.

Цитата
PFelix написал:
2. а разве сделки могут проходить как-то иначе (не между временными срезами).
Еще раз:
Цитата
Sergey Gorokhov написал:
стаканы едут срезами, также как и таблица торгов, только срезы обновляются чаще.
а таблица обезличенных сделок, едет сплошным потоком.
Значит, если была сделка, будет колбек OnAllTrade, но не факт что этот колбек попадет в срез стакана.
Банально это значит что стакан может обновиться два раза, а между этими обновлениями OnAllTrade сработает десять раз.

Цитата
PFelix написал:
Ну, и и к вопросу,
если биржа транслирует сделки и изменения в  стакане последовательно, а сервер брокера их также последовательно ретранслирует, то нарушений в последовательности быть не должно.
Разумеется, стакан претерпевает от среза до среза несколько изменений.
Важно, что все протранслированные сделки были ДО текущего состояния стакана, а те которые будут протранслированы позже, значит -- позже того же состояния стакана.
Также прошу заметить:
1. я на этом не настаиваю, просто хочется понять как работают ваши алгоритмы.
Последовательность не гарантируется.

Цитата
PFelix написал:
2. разумеется, если я не прав (не так они работают, как я описАл), никто за несинхронизацию претензий к вам предъявлять не собирается.
Еще раз:
Цитата
Sergey Gorokhov написал:
никакой синхронизации биржевых потоков со стороны QUIK нет, и не будет.
 
Для особо настойчивых хочу сообщить, что синхронизацизировать эти потоки вообще невозможно.
Если я правильно понял протокол биржи то эти потоки биржа выплевывает по протоколу UDP.
если кто-то из брокеров что-то не получил, то это проблема брокера.
Он конечно может запросить пропуски по протоколы TCP, но это ему нужно?
Кроме того, полагаю, что сервер брокера делает парсинг потоков чтобы раздать их клиентам.
Период раздачи информации биржей для срочного рынка от 10 мс и более.
Делают даже специальные задержки чтобы жизнь не казалась медом.
 
Спасибо.
это ПЕРВОЕ.
Второе:
если речь о синхронизации, есть ли алгоритм ЛУЧШЕ, чем я предложил (даже понимая, что брокер может потерять отдельную  передачу)?
 
И третье.
Если Вы, конечно, правы относительно протокола UDP.
Биржа, ЧТО, разными протоколами данные шлет?
Ленту - одним (TCP, БЕЗ пропусков), остальное - другим?
 
Цитата
PFelix написал:
И третье.
Если Вы, конечно, правы относительно протокола UDP.
Биржа, ЧТО, разными протоколами данные шлет?
Ленту - одним (TCP, БЕЗ пропусков), остальное - другим?
посмотрите эту статью
https://habrahabr.ru/company/itinvest/blog/243657/
 
Вот еще информация к размышлению.
Результаты тестирования серверов биржи в 2015 году показали следующее:
Максимальная производительность серверов Центрального Звена ТКС в ТЦ Space.
Скорость обработки в сек:
Транзакции 18884; Заявки 10782; Cделки 1775.
 
Цитата
PFelix написал:
И третье.
Если Вы, конечно, правы относительно протокола UDP.
Биржа, ЧТО, разными протоколами данные шлет?
Ленту - одним (TCP, БЕЗ пропусков), остальное - другим?

Если говорит о Московской бирже, то там UDP не используется, только TCP.
 
Цитата
Николай Камынин написал:
Цитата
PFelix   написал:
И третье.
Если Вы, конечно, правы относительно протокола UDP.
Биржа, ЧТО, разными протоколами данные шлет?
Ленту - одним (TCP, БЕЗ пропусков), остальное - другим?
посмотрите эту статью
https://habrahabr.ru/company/itinvest/blog/243657/

в QUIK протокол FAST не используется.
 
Цитата
Николай Камынин написал:
Вот еще информация к размышлению.
Результаты тестирования серверов биржи в 2015 году показали следующее:
Максимальная производительность серверов Центрального Звена ТКС в ТЦ Space.
Скорость обработки в сек:
Транзакции 18884; Заявки 10782; Cделки 1775.
Почему количество сделок на порядок ниже количества заявок? Получается, что сервер биржи на каждые 10 заявок успевает выполнить только 1 сделку? И если грубо сделать вывод , то только один человек из 10 может получить запланированную им прибыль, остальные 9 уже изначально окажутся в проигрыше? А из этого следует, что шанс, что либо заработать на бирже с помощью робота 1 к 10. И все это происходит из за низкой скорости обработки данных пользовательских запросов сервером биржи?
человек (не робот)
 
Очень многие заявки (90%) отменяются и переустанавливаются заново.
 
Цитата
Борис Гудылин написал:
Очень многие заявки (90%) отменяются и переустанавливаются заново.
По каким причинам могут отменяться заявки в таком большом количестве?  Сразу скажу я не пытаюсь принизить роль разработчиков и понимаю, что такую сложную программу трудно синхронизировать по времени и нет даже особого смысла. Поэтому какой-то "хаос" в программе будет все равно, все зависит на каком уровне может быть не стыковка (на мкс или мс, не думаю, что современные технологии передачи данных через интернет могут обеспечить нс). Думаю, что не стыковки во времени в программе  (у меня программа работает в винде), могут быть на уровне 10-20 мс и далее в сторону мкс.Поэтому просто пытаюсь понять реальные возможности программы Квик. А так как я еще тут новичек, то хотелось бы понять почему может отменяться такой большой процент заявок?  Ведь в таком случае вероятность выигрыша приближается к 10%. А ведь утверждается, что роботы могут получать прибыль в 50% и до 80%. Как это можно объяснить теоретически? (код не прошу, это конечно деньги и он секретный в коммерческом плане) Но должна ведь быть какая то теория для возможности построения таких роботов? Теория вероятности, которая построена 50 на 50, тут видимо не работает?
Цитата
и переустанавливаются заново
и кем переустанавливаются? Роботами пользователей? (Если транзакция не прошла, и в колбеке пришло соответствующее сообщение по транзакции)
человек (не робот)
 
Цитата
Николай Камынин написал:
Кроме того, полагаю, что сервер брокера делает парсинг потоков чтобы раздать их клиентам.
Период раздачи информации биржей для срочного рынка от 10 мс и более.
Делают даже специальные задержки чтобы жизнь не казалась медом.
Вот еще один момент из этой темы не понятен, почему период раздачи 10 мс это приблизительно понятно, пользовательская операционная система не способна прочитать данные выше этой скорости( не RTC и прочие),  линукс возможно может работать чуть быстрее винды, но не на порядок, а значительно меньше. Поэтому вот какой вопрос, реальное время обработки сделок в программы быстрее, чем те срезы информации которые мы получаем (кратные примерно 10 мс), так? И часть информации получается, что мы не видим? И графики минутные я думаю тоже не очень получаются точные, так как система ведет суммирование тоже по аналогичным срезам, может быть чуть меньшим? (Остальные временные интервалы должны более или менее совпадать наверно.) Еще вопрос - Какая информация в программе более точно и более быстро передается пользователю и более соответствует реальным данным в процессе совершения сделок в программе на ваш взгляд? Мне не нужно точных ответов, так как их я думаю нет, никто не может залезть в процессор или ядро или сразу в несколько потоков и посмотреть что куда идет, но у многих уже есть личный опыт, и сформировалось свое мнение, вот интересно было бы это услышать.
человек (не робот)
 
Цитата
Андрей написал:
Цитата
Борис Гудылин   написал:
Очень многие заявки (90%) отменяются и переустанавливаются заново.
... Как это можно объяснить теоретически? (код не прошу, это конечно деньги и он секретный в коммерческом плане) Но должна ведь быть какая то теория для возможности построения таких роботов? Теория вероятности, которая построена 50 на 50, тут видимо не работает?
Цитата
и переустанавливаются заново
и кем переустанавливаются? Роботами пользователей? (Если транзакция не прошла, и в колбеке пришло соответствующее сообщение по транзакции)
Андрей, теория вероятностей это вовсе не 50 на 50, а рынок вовсе не случайное блуждание.

Есть в теорвере старая задачка на случайное блуждание - про пьяницу, который выходит из кабака и на каждом перекрестке поворачивает случайным образом
(0.25-0.25-0.25-0.25) в одну из четырех сторон (планировка - как на листке в клеточку, скорость - постоянна).
На какое расстояние в среднем удалится пьяница от кабака за время T?
Ответ - расстояние растет по корню квадратному из Т.

А теперь к рынку.
Как меняется средняя высота свечек в зависимости от таймфрейма?
Первая ловушка - она меняется по тому же закону. Как бы, начинается новая свечка и растет она в течение времени ТФ. Можете проверить по индикатору
ATR. Правда скорость (волатильность) непостоянна, но в первом приближении этим результатом можно пользоваться. Из него, кстати, следует и относительная
"гладкость" движения цены на больших ТФ. Кто-то называет это "шумом".  

Практическое соображение - на каком ТФ надо работать, если торговая система работает в плюс, масштабируется по ТФ и можно отвлечься от ограничений
физиологии трейдера, ликвидности, комиссий, ...?
Ответ - чем меньше ТФ, тем лучше.

Сравним часовики и минутки. Свечек на минутках - в 60 раз больше, сделок можно сделать в 60 раз больше (масштабируемость), но высота свечек (наш потенциал прибыли) примерно в 8 раз меньше (корень квадратный из 60). Соответственно - прибыль в 8 раз больше (работы, повторюсь, в 60 раз больше). Начиная с какого-то ТФ вниз роботы начинают иметь бесспорное преимущество.

Ловушка 2. Случайное блуждание и нормальное распределение (гауссиана, колокол). Толстые хвосты, логнормальное распределение.

Ловушка 3. ЦПТ (центральная предельная теорема). Если замешать много-много случайных величин с разными характеристиками распределений, то получим нормальное распределение.

Очень велик соблазн воспользоваться близостью рынка к случайному блужданию и отработанным аппаратом математической статистики. Для кого-то гипотеза
эффективного рынка (EMH) уже умерла, кто-то про нее еще не знает, но псевдонобелей она наплодить успела.

Но есть и альтернатива - строить исследование устройства рынка на отличиях от случайного блуждания, развивать гипотезу фрактального рынка (FMH). Но путь это вовсе не прост, для энтузиастов.

На многие Ваши вопросы есть ответы, есть чисто аналитические, еще есть опыт, есть результаты изучения и измерений. Ордерлоги биржи еще можно найти и посмотреть, много интересного можно найти в измерении полноты и временных характеристик получения данных для разных таблиц.

А частные вопросы - заявки снимаются трейдером (руками или роботом) сообразно постоянно меняющейся ситуации и переустанавливаются точно так же.
 
Цитата
Андрей написал:
По каким причинам могут отменяться заявки в таком большом количестве?
Сами пользователи их ставят и снимают без совершения сделок, потому что сделки проходят только по одной цене в стакане, где встречаются спрос и предложение, а по остальным ценам оставшиеся заявки просто висят неисполненными в очереди, пока не будут исполнены позже либо сняты. Собственно их вы и видите в стакане... Заявок всегда больше, чем сделок по определению. Так работает аукцион.

Тут дело не в Quik и не в бирже, а совсем в другом. Аукцион в принципе подразумевает множество заявок, и в конце сделку по достижению цены исполнения аукциона. Любой аукцион так работает. Найдите видео реального аукциона какого-нибудь, где люди поднимают руки десятки раз, а ведущий зачитывает цену и в конце бьёт молоточком. Посчитайте сколько проходит заявок перед тем как будет совершена одна сделка, и сразу поймёте принцип.
 
ДД !!!
Связанная ссылка (для интересующихся): https://forum.quik.ru/messages/forum10/message4422/topic496/#message4422
В свете вышесказанного (во всяком случае от меня и ответов на мои вопросы) возник следующий вопрос:
Правильно ли я понимаю, что:
1. в случае, когда изменения в стакане обусловлены лишь конкретной сделкой,
2. учитывая приоритетность потоков данных;
3. ОДНОЗНАЧНО;
              а теперь утверждение:
калбеки, отражающие данное изменение, придут в порядке:
1. заказанный от SetUpdateCallback (от CreateDataSource);
2. OnAllTrade;
3. OnQuote.
И НИКАК ИНАЧЕ?

На всякий случай:
Иными словами:
Изменение состояния, Связанное с одним событием по конкретному инструменту, НЕ МОЖЕТ БЫТЬ ОТРАЖЕНО в "стакане" раньше, чем в ленте?
Заранее спасибо.
 
PFelix,
SetUpdateCallback (от CreateDataSource) и OnAllTrade, OnQuote транслируются разными потоками которые между собой никак не синхронизируются.
Значит и никакой гарантии в определенной последовательности дынных между ними нет и не может быть.
Потому что синхронизация, это ни что иное как искусственная задержка. Как уже несколько раз было сказано и еще раз повторим, со стороны QUIK записи отправляются клиенту тогда когда их получит сервер и в том порядке как их получит сервер, и не важно какое время у конкретной записи, никаких принудительных задержек в этом месте нет и не будет, т.к. любые принудительные задержки есть великое зло.
Страницы: 1
Читают тему (гостей: 1)
Наверх