Medición del orderflow: reinicios, unidades y disponibilidad · 4 / 5
Adelanto y retraso del orderflow: alinea tiempo del evento y de llegada
Una operación puede ocurrir antes de un movimiento y llegar al sistema después. Ordenar datos descargados por hora de ejecución puede crear una señal adelantada que no existía en tiempo real. Conserva ambos relojes al evaluar decisiones.
Athenum7 minActualizado:
Conserva tres marcas temporales distintas
El tiempo de evento indica cuándo la plataforma afirma que ocurrió la ejecución. El de generación indica cuándo el proveedor ensambló el mensaje. El de recepción local indica cuándo llegó al recolector. Agrupación de mensajes, red, reconexiones y desfases de relojes pueden separarlos.
Usa la semántica documentada de la plataforma, no adivines por el nombre corto del campo. Bybit distingue el tiempo de ejecución y el de generación del mensaje. Ninguno es automáticamente la llegada a tu sistema. Registra la recepción al ingerir datos y conserva zona horaria, precisión y sincronización de relojes.
Reproduce lo que estaba disponible para decidir
Para decidir a una hora local t, incluye únicamente observaciones recibidas hasta t y después aplica el retraso normal de procesamiento. Una corrección posterior puede mejorar el gráfico histórico sin cambiar lo que se sabía antes. Conserva primera recepción y versiones posteriores en lugar de sobrescribir el pasado.
Las estimaciones entre plataformas también necesitan límites del error de reloj. Un adelanto medido de 20 milisegundos convence poco si los relojes pueden diferir 100. Incluso una precedencia temporal fiable no demuestra causalidad ni una oportunidad ejecutable tras costes, latencia e incertidumbre de llenado.
Ejemplo: un adelanto aparente de 100 ms llega 200 ms después del evento comparado
En esta cronología construida, la operación A ocurre a las 12:00:00.100 y llega a .400. La actualización de precio B ocurre a .200 y llega a .220. Ordenar por evento sitúa A 100 ms antes de B, pero la aplicación recibe B 180 ms antes que A.
Una decisión a .250 puede ver B y no A. Un backtest que incorpore A a la fila de evento .100 y opere a .250 filtra información. El primer uso posible de A es a partir de .400 más procesamiento y latencia de orden; para entonces pueden haber cambiado oportunidad y precios ejecutables.
| Observación | Hora del evento | Llegada local | ¿Disponible a .250? |
|---|---|---|---|
| Operación A | 12:00:00.100 | 12:00:00.400 | No |
| Precio B | 12:00:00.200 | 12:00:00.220 | Sí |
Ampliar el diagrama- .100: ocurre la operación A
- .220: llega el precio B
- .250: la decisión solo ve B
- .400: finalmente llega A
Una repetición tras reconectar no es actividad nueva
Los mensajes almacenados pueden llegar juntos tras una reconexión y describir ejecuciones antiguas. Un pico de llegadas puede ser recuperación de red. Guarda identificadores, deduplica con la identidad correcta y revisa la distribución temporal de eventos antes de interpretar el pico. No elimines operaciones distintas por compartir mensaje o campo de secuencia.
Antes de actuar
- Conserva tiempos de evento, mensaje y recepción.
- Reproduce decisiones con lo recibido antes del corte.
- Mantén retrasos y revisiones sin anticipar su conocimiento.
- Compara el adelanto con el error de reloj y la latencia ejecutable.
Comprueba lo aprendido
La operación X ocurre a .120 y llega a .310. El precio Y ocurre a .180 y llega a .210. ¿Puede una decisión a .250 usar X para predecir Y?
Ver la respuesta explicada
No. X ocurrió 60 ms antes de Y, pero llega 100 ms después de Y y 60 ms después de la decisión. A .250 se observa Y, no X. Usar X allí es un error de disponibilidad, cualquiera que sea el orden de los eventos.