Plataformas · Software · Proveedores · Mercados
Una operación ocurre una sola vez. Cuando llega a una base de datos, lleva tres o cuatro horas distintas, ninguna de las cuales es incorrecta, y todas miden algo ligeramente diferente. La mayoría de las discusiones sobre conciliación son, en realidad, discusiones sobre a qué reloj se refería alguien.
Los relojes en un recorrido habitual
| Marca de tiempo | Quién la establece | Intervalo habitual respecto a la anterior |
|---|---|---|
| Hora del motor de casación | El centro de negociación, en el momento de la casación | Punto de referencia |
| Hora de publicación del feed | La capa de distribución del centro de negociación | 10 a 500 microsegundos |
| Hora de recepción en la pasarela | Su broker o proveedor | 1 a 50ms a través de redes públicas |
| Hora de recepción local | Su propio proceso | 0.1 a 20ms, más la variación de planificación |
| Hora de escritura en la base de datos | Su capa de almacenamiento | Cualquier intervalo, y no corresponde a un evento de mercado |
La última fila es la que causa problemas, porque es la más fácil de registrar y la menos significativa. Ordenar los eventos por la hora de escritura en la base de datos produce una secuencia que suele ser correcta y, ocasionalmente, bajo carga, muy incorrecta.
De dónde viene la discrepancia
- Relojes diferentes. El centro de negociación, la pasarela y su host tienen cada uno su propio reloj, sincronizado con distintos niveles de rigor.
- Eventos diferentes. La casación, la publicación, la recepción y el almacenamiento son cuatro momentos distintos, no cuatro lecturas de uno solo.
- Resoluciones diferentes. Un feed en milisegundos y un registro en microsegundos nunca coincidirán exactamente, y el redondeo oculta la dirección del error.
- Cambio de hora y convenciones del centro de negociación. Son menos frecuentes que antes, pero no han desaparecido, y siempre se descubren el día en que cambian los relojes.
Qué hacer al respecto
- Almacene cada marca de tiempo que reciba, cada una en su propia columna, en UTC.
- Registre su propia hora de recepción con una fuente monotónica, no con la hora del reloj de pared.
- Supervise la desviación entre su host y una referencia, y configure alertas ante una deriva en lugar de comprobarla después de un incidente.
- Elija un reloj como clave de ordenación, deje constancia de esa decisión y haga que cada informe indique cuál utilizó.
- Cuando dos sistemas discrepen, compare el mismo reloj en ambos antes de suponer que alguno está averiado.
El objetivo no es hacer que los relojes coincidan, porque miden cosas diferentes y nunca lo harán. Se trata de saber de qué reloj procede cada número, para que una discrepancia sea un dato sobre el recorrido y no un misterio sobre los datos.
Preguntas frecuentes
¿Qué marca de tiempo debería almacenar?
Todas, en columnas separadas. Almacenar solo una es una decisión irreversible, y el coste de tres columnas bigint es insignificante frente al de reconstruir el historial porque conservó el reloj equivocado.
¿Cuánto suelen diferir la hora del mercado y la hora local?
En una conexión minorista a través de la internet pública, normalmente entre 20 y 150ms, con desviaciones ocasionales muy superiores. En un entorno de coubicación, la diferencia se reduce a microsegundos. El spread importa más que la cifra.
¿NTP es suficiente?
Para estrategias medidas en segundos, sí, normalmente con una precisión de unos pocos milisegundos. Para cualquier cosa medida en microsegundos, se necesitan PTP y marcas de tiempo por hardware, y hay que supervisar la desviación en lugar de darla por supuesta.
