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

О синхронизации локального времени с сервером точного времени.
 
Раз в час синхронизирую время с сервером точного времени ntp1.vniiftri.ru. Сразу после этого  локальное время и время биржи если и отличаются, то не слишком заметно.
Но за час расхождение достигает нескольких секунд.  

Вы меня правильно поняли. У меня было подозрение, что все именно так. Есть опыт / идеи борьбы с проблемой?Время синхронизировано на компе и сервере. Это не проблема. Я уже говорил. Поскольку сСтакан формируется на бирже, а OnQoute - на терминале пользователя. SERVERTIME указывает время последней генерации, которая происходит позже. Это проблема. Для сделок. например, можно узнать точное время именно биржи, а для стакана, как я подозреваю - нет. Это "нихт гду."

Спасибо.  

Такой сложный вопросили раскрыл САКРАЛЬНОЕ ЗНАНИЕ?

Николай, не напускайте туману.
1. В скрипт калбеки по ленте приходят в нужном порядке.
2. Вопрос был адресован3 Я не вчера родился, а Вы про меня мало, что знаете.
4. Для начала бы понять, един ли источник информации, т.е. сервер ли ПРОСТО "перетранслирует" биржевые пакеты или тот стакан, который приходит в терминал, "рождается" по определенному алгоритму не сервере брокера.

Рождается на сервере брокера. Выше был намек.
ну и потом, это ведь очевидно, что сервер и терминал общаются по протоколу, отличному от биржевого.
хотя бы потому, что бирж много, а терминал - один.

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

Иван Ру,
Возможно я не понял Вашу задачу, но хочу обратить внимание на неточность в Ваших рассуждениях.
------------------------------------------
Во-первых, тот факт что пакеты в TCP соединении  приходят последовательно  не может знать пользователь винды.
Речь идет о пакетах протокола TCP и они собираются стеком TCP, что пользователем не доступно.
---------------------------------------------
Во-вторых, интернет построен на маршрутизаторах - а это и есть разное время движение пакетов и возможность их прихода как раньше так и позже.
--------------------------------------------------------
В-третьих, время сервера брокера - это время когда в терминал пришла последняя партия данных с сервера. Это может быть и не стакан.
----------------------------------------------------
В-четвертых, поток сделок тоже идет блоками. В одном блоке, который придет в одно время сервера будут сделки с различным временем биржи.
-----------------------------------------------------
В итоге,
сделкам совершенным в разное время будет соответствовать одно и тоже время сервера брокера, а это значит,
сделки могут опередить заявки в стакане, по которым они совершены.
---------------------------------------
Поэтому в терминале QUIK и на обычных каналах интернет возможна синхронизация сделок и заявок лишь очень примерно.
----------------------
На это я и пытался обратить Ваше внимание.

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

Для таблицы обезличенных сделок, "приход" сделки и изменение таблицы, это одно и тоже.

Еще раз:
Значит, если была сделка, будет колбек OnAllTrade, но не факт что этот колбек попадет в срез стакана.
Банально это значит что стакан может обновиться два раза, а между этими обновлениями OnAllTrade сработает десять раз.

Последовательность не гарантируется.

Еще раз:

Спасибо.
это ПЕРВОЕ.
Второе:
если речь о синхронизации, есть ли алгоритм ЛУЧШЕ, чем я предложил (даже понимая, что брокер может потерять отдельную  передачу)?

посмотрите эту статью
https://habrahabr.ru/company/itinvest/blog/243657/

Если говорит о Московской бирже, то там UDP не используется, только TCP.

Почему количество сделок на порядок ниже количества заявок? Получается, что сервер биржи на каждые 10 заявок успевает выполнить только 1 сделку? И если грубо сделать вывод , то только один человек из 10 может получить запланированную им прибыль, остальные 9 уже изначально окажутся в проигрыше? А из этого следует, что шанс, что либо заработать на бирже с помощью робота 1 к 10. И все это происходит из за низкой скорости обработки данных пользовательских запросов сервером биржи?

По каким причинам могут отменяться заявки в таком большом количестве?  Сразу скажу я не пытаюсь принизить роль разработчиков и понимаю, что такую сложную программу трудно синхронизировать по времени и нет даже особого смысла. Поэтому какой-то "хаос" в программе будет все равно, все зависит на каком уровне может быть не стыковка (на мкс или мс, не думаю, что современные технологии передачи данных через интернет могут обеспечить нс). Думаю, что не стыковки во времени в программе  (у меня программа работает в винде), могут быть на уровне 10-20 мс и далее в сторону мкс.Поэтому просто пытаюсь понять реальные возможности программы Квик. А так как я еще тут новичек, то хотелось бы понять почему может отменяться такой большой процент заявок?  Ведь в таком случае вероятность выигрыша приближается к 10%. А ведь утверждается, что роботы могут получать прибыль в 50% и до 80%. Как это можно объяснить теоретически? (код не прошу, это конечно деньги и он секретный в коммерческом плане) Но должна ведь быть какая то теория для возможности построения таких роботов? Теория вероятности, которая построена 50 на 50, тут видимо не работает?
и кем переустанавливаются? Роботами пользователей? (Если транзакция не прошла, и в колбеке пришло соответствующее сообщение по транзакции)

Андрей, теория вероятностей это вовсе не 50 на 50, а рынок вовсе не случайное блуждание.

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

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

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

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

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

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

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

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

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

А частные вопросы - заявки снимаются трейдером (руками или роботом) сообразно постоянно меняющейся ситуации и переустанавливаются точно так же.

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

На всякий случай:
Иными словами:
Изменение состояния, Связанное с одним событием по конкретному инструменту, НЕ МОЖЕТ БЫТЬ ОТРАЖЕНО в "стакане" раньше, чем в ленте?
Заранее спасибо.