Измерение orderflow: сбросы, единицы и время доступности · 4 / 5
Опережение orderflow: согласуйте время события и получения
Сделка может произойти раньше ценового движения, но прийти в систему позже. Сортировка выгруженных данных по биржевому времени способна создать недоступный в реальности опережающий сигнал. Сохраняйте оба времени.
Athenum7 минОбновлено:
Храните три разные временные метки
Время события — когда, по утверждению биржи, произошло исполнение. Время формирования сообщения — когда поток собрал обновление. Локальное получение — когда его принял сборщик. Пакетная отправка, сеть, переподключение и смещение часов могут разделять эти моменты.
Используйте документированную семантику полей, а не догадку по короткому имени. Bybit различает время исполнения и формирования сообщения публичной ленты. Ни одно автоматически не равно вашему получению. Записывайте локальную метку при приёме, сохраняя пояс, точность и сведения о синхронизации часов.
Воспроизводите доступную решению информацию
Для решения в локальный момент t берите лишь наблюдения, полученные до t, затем учитывайте обычную задержку обработки. Поздняя корректировка улучшает историческое отображение, но не меняет прежнее знание. Сохраняйте первую запись и версии, не перезаписывая историю.
Межбиржевое опережение требует границ ошибки часов. Измеренные 20 мс малоубедительны при возможном расхождении 100 мс. Даже надёжный временной порядок не доказывает причинность или исполнимую возможность после затрат, задержек и неопределённости исполнения.
Пример: кажущееся опережение на 100 мс приходит через 200 мс после сравниваемого события
В учебной хронологии сделка A происходит в 12:00:00.100, а приходит в .400. Обновление цены B происходит в .200 и приходит в .220. По событиям A на 100 мс раньше B, но приложение получает B на 180 мс раньше A.
Решение в .250 видит B, но не A. Бэктест, добавивший A в строку события .100 и торгующий в .250, использует недоступное знание. A можно использовать не раньше .400 плюс обработка и отправка заявки; возможность и цены к тому моменту могли измениться.
| Наблюдение | Время события | Локальное получение | Доступно в .250? |
|---|---|---|---|
| Сделка A | 12:00:00.100 | 12:00:00.400 | Нет |
| Цена B | 12:00:00.200 | 12:00:00.220 | Да |
Увеличить схему- .100: происходит A
- .220: сборщик получает B
- .250: решение видит только B
- .400: наконец приходит A
Повтор после подключения — не новая вспышка торгов
Накопленные сообщения могут прийти почти одновременно после восстановления связи и описывать старые исполнения. Рост частоты получения бывает следствием сети, а не рынка. Сохраняйте идентификаторы, удаляйте повторы по правильной идентичности сделки и проверяйте времена событий. Не удаляйте разные сделки лишь из-за общего сообщения или поля последовательности.
Перед решением
- Сохраняйте время события, сообщения и локального приёма.
- Воспроизводите решения по полученному до отсечения.
- Не переносите поздние записи и версии в раннее знание.
- Сравнивайте опережение с ошибкой часов и задержкой исполнения.
Проверьте понимание
Событие X имеет время .120, получение .310. Цена Y — событие .180, получение .210. Может ли решение в .250 использовать X для предсказания Y?
Показать ответ с объяснением
Нет. X произошло на 60 мс раньше Y, но получено на 100 мс позже Y и на 60 мс позже решения. В .250 известно Y, не X. Использование X — ошибка доступности независимо от порядка событий.