Кто может дать один денек данных futures_typeA.txt FORTS ?

Gypsy, Ясно.

tranquility, 

 плаза — точнее.

интересно, как оно там может точнее, если timestamp биржевой везде одинаковый, что в плазе, что в fast.

Андрей К, не знаю, за что купил — за то продал. Вот переписка с техподдержкой отдела что данные (typeB) продавал:
вопрос в поддержку:

Я решил проверить, насколько отличаются данные, которые были приобретены у Вас (сделки RIH8 + лучшие заявки за январь 18 года) с теми, которые можно восстановить по ордерлогу, который был записан непосредственно через шлюз Plaza-II. Оказалось, что времена сделок и ордеров отличаются на +-2 миллисекунды (я не считаю те данные, которые загружаются из снэпшота до начала торгов), причем, как в одну, так и в другую сторону (см. вложения, там столбцы справа — это купленные данные истории, слева — реконструировано с ордерлога плазы). Можете объяснить, с чем это связано?

короткий ответ:

Добрый день, вероятно расхождение (в вашем примере увидел 1 мс) связано с задержкой записи логов.

опять вопрос:

Не могу быть удовлетворен таким ответом. Если бы это была задержка, то отклонение было бы только в одну сторону (в левых столбцах было бы большее время, причем практически всегда). Однако, если вы внимательно посмотрите присланные скриншоты, увидите, что отклонение в обе стороны наблюдается. Скажите, через Plaza-II в ордерлоге время ордеров транслируется непосредственно биржей и не должно изменяться брокером? Во вложение прикладываю сравнение файлов со сделками, т.к. в форму вопроса можно было прикрепить только один файл.

потом был какой-то ответ про погрешность в 3 мс, его не нахожу что-то, зато позже еще более развернуто и понятно ответили:

Добрый день, мне кажется данные, которые вы записали (левый столбец) получен разными методами, объясню почему это важно. При «прохождении» данных через базу SQL, значение поля moment всегда оканчивается только на 0,3,7 на некоторых скриншотах (как с правой так и с левой стороны) это хорошо видно, коллеги говорят это особенность Microsoft SQL. Т.е. непосредственно в Plaza2 это поле транслируется корректно и данные записанные без посреднечества SQL наиболее точны. Значения, которые указаны в платной версии данных, наиболее приближены к реальности  и округлены по правилам математического округления (есть поле moment_ns - транслирующее наносекунды можно с ним сравнить), вот для сравнения 3 первые сделки из второй картинки. 1954191244 — .218 235 100 2018-01-29 10:00:00.217;1517209200218235100
1954191245 — .218 778 900  2018-01-29 10:00:00.220;1517209200218778900 1954191247 — .219 488 900  2018-01-29 10:00:00.220;1517209200219488900 Выделены номера сделок, подчеркнуто последние 9 цифр поля moment_ns, красным — moment из базы SQL, самое последнее значение это время в UNIX формате с точностью до наносекунд.

Так что если Вы гоняете эти купленные данные на своих тестах, где важна точность до 1 мс, стоит иметь ввиду такой момент…

tranquility, 
уже пол второго ночи, лень пока писать про ваш диалог. Вкратце про это

потом был какой-то ответ про погрешность в 3 мс, 

у фортс до прошлого месяца данные «нарезались» каждые 3 мс. То есть данные на фортс всегда копились в течении 3 мс и рассылались. В связи с этим всплыла задержка 3мс.

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

но в любом случае, правильнее ориентировать на время ядра биржи. Я так понял, в вашей переписке это moment_ns. То есть это биржевое время ядра, в момент которого регистрируются сделки/заявки

Андрей К, ну, у меня режим немного другой, поэтому сейчас отвечу) Речь в переписке идет не о разнице между plaza2 и fast, а между историческими данными что продаются биржей и аналогичными что можно восстановить по ордерлогам plaza2 (которые можно взять из опубликованных .qsh файлов). Вот, результат отличается, разница между биржевыми временами сделки/ордера отличается на +-2мс:
(это файл сделок с ордерами)


это файл только сделок: